存储过程的性能差异：SqlCommand 与 SSMS
存储过程的执行时间在 SQL Server Management Studio 之间可能存在显着差异（ SSMS）和 System.Data.SqlClient.SqlCommand，即使没有参数嗅探。根本原因可能在于每个执行环境启用的 SET 选项不同。
通过使用 SQL Server Profiler，发现 SSMS 执行了 .NET Sql Client Data Provider 省略的多个 SET 命令。这些 SET 选项可以影响查询计划和性能。在这种情况下，作为罪魁祸首出现的一个关键 SET 选项是：
SET ARITHABORT ON
启用此 SET 选项时，使用算术运算的查询可能会导致溢出、除以零或其他异常情况会提前停止。此行为与 SET ARITHABORT OFF 的默认设置不同，后者允许发生异常。
因此，存储过程的执行计划和性能可能会受到 SET ARITHABORT 选项的影响。如果存储过程中的算术运算受此设置的影响，则可能会导致 SSMS 和 SqlCommand 之间的执行时间差异。
为了缓解此问题，建议仔细检查应用程序使用的 SET 选项连接到 SQL Server。通过在 SqlCommand 中使用与 SSMS 使用的相同的 SET 选项，可以避免性能不一致。此外，利用 SQL Server Profiler 识别活动 SET 选项是一种很有价值的调试技术。
其他因素，例如连接字符串参数、事务行为和 MARS（多个活动结果集）设置，也会影响性能并应被视为潜在的影响因素。
以上是为什么我的存储过程在 SSMS 中比在 SqlCommand 中运行得更快？的详细内容。更多信息请关注PHP中文网其他相关文章！
