为什么我的 SQL 查询只在生产环境中变慢？

对任何开发者来说，这都是一个令人沮丧的情况。有用户反馈应用中的某个功能卡住了。你复制了应用程序执行的准确 SQL 查询语句，粘贴到 SQL Server Management Studio (SSMS) 中，然后点击 Execute（执行）。它仅用了 0.02 秒就执行完毕。你再次运行它，速度依然极快。然而，在应用程序内部，它却持续超时。这种情景通常指向一个被称为参数嗅探的常见问题。

今天是 2026 年 8 月 10 日，对于使用数据库驱动的应用程序的开发者而言，理解参数嗅探至关重要。随着应用程序的发展和数据分布的变化，可能会出现性能问题，尤其是在生产环境中。

什么是参数嗅探？

当参数化查询或存储过程首次运行时，SQL Server 会查看当时传入的参数。它使用这些值来估计将返回多少行，并编译出一个针对该特定情况量身定制的执行计划。随后，该执行计划会被缓存以供将来使用。

然而，这可能会导致问题。例如：

• 场景 A： 首次运行传递了一个返回 5 行的参数。SQL Server 使用 Index Seek 创建了一个计划，这种方式快速且高效。
• 场景 B： 稍后，另一个用户传递了一个返回 500,000 行的参数。SQL Server 复用了场景 A 中缓存的计划，但这并不适合这个更大的数据集。服务器难以将轻量级的计划应用于海量数据集，从而导致性能缓慢甚至超时。

如何识别参数嗅探问题

要捕获缓存中的不良执行计划，你可以检查计划缓存（plan cache）。这有助于你查看在编译与执行期间分别使用了哪些参数值。以下是一个快捷的 SQL 命令，可用于查找运行速度低于预期的查询：

SELECT TOP 10 qs.execution_count AS [Exec_Count],
    (qs.total_elapsed_time / 1000.0) / qs.execution_count AS [Avg_Duration_ms],
    (qs.total_worker_time / 1000.0) / qs.execution_count AS [Avg_CPU_ms],
    qs.total_logical_reads / qs.execution_count AS [Avg_Logical_Reads],
    SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1,
    ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset) / 2) + 1) AS [Query_Text],
    qp.query_plan AS [XML_Execution_Plan]
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE qs.execution_count > 5
ORDER BY (qs.total_elapsed_time / qs.execution_count) DESC;

当你运行此命令时，你可以点击 XML_Execution_Plan 列以在 SSMS 中查看实际的图形化执行计划。在属性窗口中查找 Parameter List；它将向你显示 Compiled Value 与 Runtime Value。如果这些值差异巨大，你很可能就找到了参数嗅探的罪魁祸首。

如何解决参数嗅探

有几种解决参数嗅探的策略，具体取决于你的 SQL Server 版本和特定的业务场景：

• 添加 OPTIMIZE FOR UNKNOWN: 该查询提示告诉 SQL Server 创建一个更通用的计划，而不是针对特定参数值量身定制的计划。
• 使用局部变量： 与其直接在存储过程中使用参数，局部变量可以帮助 SQL Server 创建更有利的计划。
• 更新陈旧的索引统计信息： 保持统计信息为最新状态可以帮助 SQL Server 在执行计划上做出更好的决策。
• 使用 Query Store： 如果启用了 Query Store，它可以帮助针对你的查询强制使用已知的良好计划。

结论

参数嗅探可能是一个棘手的问题，会导致生产环境中的性能问题。通过理解其工作原理以及如何识别和修复该问题，你可以提升 SQL 查询的性能。

优点

• 有效帮助识别慢查询。
• 提供对执行计划的深入了解。
• 提供多种解决方案策略。

缺点

• 需要了解 SQL Server 内部原理。
• 可能需要根据具体场景进行调整。
• 修复方案可能因 SQL Server 版本而异。

注意事项

本文仅供教育目的使用。在依赖相关内容前，请务必将所有占位符值替换为你的实际数据，并对照原始来源核实声明。

常见问题

• 什么是参数嗅探？ — 参数嗅探是指 SQL Server 使用查询首次执行时的参数值来创建缓存的执行计划，而该计划对于后续的执行可能并非最佳。
• 为什么参数嗅探会导致查询变慢？ — 当缓存的执行计划不适合后续执行的数据大小或数据分布时，就可能导致查询变慢。
• 如何识别参数嗅探问题？ — 你可以检查计划缓存（plan cache），并将编译时的参数值与运行时值进行比较，以发现差异。
• 什么是执行计划？ — 执行计划是 SQL Server 用于执行查询的路线图，详细说明了它将如何检索数据。
• 如何解决参数嗅探？ — 你可以通过使用类似 OPTIMIZE FOR UNKNOWN、局部变量、更新统计信息或使用 Query Store 等技术来解决。
• 参数嗅探会影响所有 SQL Server 版本吗？ — 是的，参数嗅探会影响多个 SQL Server 版本，尤其是在数据分布不均匀的情况下。

标签

#database #sql #performance #queryoptimization #parametersniffing #sqlserver #executionplan #databases