Sql Server查询优化

我正在优化一个使用大量动态Sql的Sql Server 2008中的大型SP。这是一个查询，它使用一些可选参数搜索数据库，并且对每个可能的参数组合都进行编码。动态sql已被证明是执行此操作的最有效方法。 sql striung包含参数，然后通过参数列表传递给sp_executesql。当使用任何参数组合运行SSMS时，它运行速度非常快（< 1秒）并返回结果。但是，从Windows窗体应用程序运行时，它有时需要相当长的时间。Sql Server查询优化

我读过ARITHABORT选项中的差异可能会导致这种情况（在SSMS中默认为ON，在ADO中为OFF），但我不确定是否打开此项可修复问题还是掩盖了它？设置上的差异是否会对查询本身产生影响？或者这是否意味着Sql Server将使用不同的缓存执行计划？如果是的话应该清除缓存和统计数据重置场地？

我也读过关于OPTION RECOMPILE设置的不同观点。我的理解是，当sp_executesql与参数列表一起使用时，每个参数组合将产生一个执行平面，但是由于参数的可能组合是有限的，这将导致优化的查询。其他消息来源说，在任何使用动态sql的SP开始时，它应该设置为ON。

我意识到不同的情况需要不同的设置，但我期待在我非常繁忙的24x7生产服务器上尝试arbritraily之前了解这些。道歉，我想我的问题归结为：

是什么原因导致SQL在SSMS和窗体窗体中运行不同？如果是ARITHABORT，那么这是一个与执行计划相关的问题还是应该将其作为服务器默认设置打开？使用动态sql运行查询的最佳方式是什么？

来源

2010-09-17 Macros

你可以在测试服务器上尝试更改吗？一般来说，无论“应该”工作，YMMV – Beth 2010-09-17 15:37:30

@Beth - 我会尝试在测试服务器上进行更改，但我主要关心的是更改内容。设置ARITHABORT可能会解决问题，但如果它实际上只是让ADO查看不同的执行计划，这看起来不像修复。我的生产数据库的尺寸也比我的测试大很多，尽管我意识到这并不理想，但我目前没有足够大的测试服务器来完全复制生产环境。 – Macros 2010-09-17 15:55:10

你见过http://articles.techrepublic.com.com/5100-10878_11-5662581.html – Beth 2010-09-17 16:00:32

在SQL事件探查器中运行跟踪以查看实际提交到服务器的内容。当然，您需要了解生产服务器上的痕迹的影响。根据我的经验，仅限于小集的非常短的跟踪对于没有每秒负载事务数很高的服务器来说不是一个大问题。此外，您可以运行跟踪服务器端，从而降低其影响，因此这是您的选择。

一旦看到实际提交到数据库的内容，这可能会帮助您了解问题。例如，有时DB库会准备语句（获取某种临时存储过程的句柄），但如果为每次发出查询完成此操作，则花费可能很高，而且对于sp_executesql不需要。无论如何，没有办法确定它是否会有帮助，直到你尝试。

来源

2011-02-16 18:57:33 ErikE

Sql Server查询优化

回答

相关问题