我正在使用大量动态Sql优化Sql Server 2008中的大型SP。它是一个查询，它使用许多可选参数搜索数据库，并且缺少对每个可能的参数组合的编码，动态sql已被证明是执行此操作的最有效方法。构建包含参数的sql striung，然后使用param列表传递给sp_executesql。当使用任何参数组合在SSMS中运行它时，它运行得非常快（<1s）并返回结果。但是，从Windows窗体应用程序运行时，有时需要相当长的时间。
我已经读过ARITHABORT选项的区别可能会导致这种情况（在SSMS中默认为ON，在ADO中为OFF）但是我不确定是否启用此功能可以解决问题还是屏蔽它？设置的差异是否会对查询本身产生影响，还是仅仅意味着Sql Server将使用不同的缓存执行计划？如果是这样，清除缓存和统计信息会重置比赛场地吗？
我还阅读了OPTION RECOMPILE设置的不同观点。我的理解是，当sp_executesql与参数列表一起使用时，每个参数组合将产生一个执行平面，但是由于参数的可能组合是有限的，这将导致优化的查询。其他消息来源说它应该在使用动态sql的任何SP开始时设置为ON。
我意识到不同的情况需要不同的设置，但我希望在我非常忙碌的24x7生产服务器上尝试arbritraily之前进一步了解这些。对于ramblings道歉，我想我的问题归结为：
是什么导致sql在SSMS和Window Forms中以不同方式运行？ 如果它是ARITHABORT，那么这是一个与执行计划相关的问题，还是应该将其作为服务器默认值打开？ 使用动态sql运行查询的最佳方法是什么？
答案 0 :(得分：0)
在SQL事件探查器中运行跟踪，以查看实际提交给服务器的内容。当然，您需要了解跟踪对生产服务器的影响。根据我的经验，限制为小集的非常短的跟踪对于没有每秒负载非常高的事务的服务器来说不是一个大问题。此外，您可以运行跟踪服务器端，以减少其影响，以便为您提供选项。
一旦您看到实际提交给数据库的内容，这可能有助于您了解问题。例如，有时DB库会准备语句（获取某种临时存储过程的句柄），但如果为每次查询发布完成，这可能会很昂贵，而且sp_executesql不需要它。无论如何，在你尝试之前，没有办法确定它是否有用。