SQL Server 编译与重编译详解：原理、场景与调优权衡

咖啡半糖

发布时间：2026-10-14| 5人浏览过

原创

当 SQL Server 接收查询或存储过程指令时，会通过语法和语义分析生成“执行计划”并缓存于内存（Plan Cache）中以实现快速重用。然而，受限于数据分布变化、架构调整或会话设置差异，系统会频繁触发“重编译”。理解这一机制对于平衡数据库 CPU 负载与查询性能至关重要。

编译机制与执行计划重用

在 SQL Server 中，任何接收到的指令（包括查询、批处理、存储过程、触发器、预编译指令及动态 SQL）都需要经过预处理才能运行。编译过程包含以下核心步骤：

语法与语义解释：检查代码逻辑的合法性。
成本估算：根据对象架构（Schema）、统计信息以及指令具体内容，评估不同执行路径的成本。
计划生成：选择当前认为成本最低的执行计划（Execution Plan）。

编译完成后，SQL Server 会将生成的执行计划缓存在内存中，该区域统称为 Plan Cache。后续遇到相同语句时，直接重用缓存中的计划，避免重复计算。这种“执行计划重用”是提升数据库响应速度的关键。

查看缓存中的执行计划

可以通过以下命令查看当前 SQL Server 服务器内存中缓存的所有执行计划。请注意，在生产环境中大规模缓存可能导致数据量大，建议仅在测试环境或了解原理时使用：

SELECT * FROM sys.[syscacheobjects];

执行计划重用的利弊权衡

执行计划的质量直接决定语句的执行速度。理论上，每次执行前都重新编译能确保获取最优计划，但在高并发场景下，每秒成百上千条指令若全部实时编译，将造成严重的资源浪费（CPU 开销）。

因此，SQL Server 在设计上试图寻找一个平衡点：

优点：重用执行计划可大幅降低 CPU 使用率，减少阻塞，显著提升高频语句的执行速度。
缺点：复用的计划基于历史数据生成，若数据分布发生剧烈变化，旧计划可能不再适用。典型的负面效应是“参数嗅探”（Parameter Sniffing），即首次执行时的参数导致生成了针对特定数据的次优计划，后续不同参数的请求被迫沿用此低效计划。

重编译（Recompile）的发生场景

为了确保数据准确性或在性能出现瓶颈时刷新计划，SQL Server 会在特定条件下放弃重用旧计划，强制进行现场编译，这一行为称为“重编译”。以下是常见的触发场景：

第1步：架构（Schema）变更触发重编译

当指令或批处理涉及的表、视图等对象发生结构性变化时，原有的执行计划可能失效，必须重编译：

添加或删除列。
创建或删除索引。
添加或删除约束条件（Constraints）。

第2步：手动调用重编译命令

用户可通过 sp_recompile 存储过程强制标记对象进行重编译：

作用于存储过程/触发器：下次执行该对象时会发生一次重编译。
作用于表/视图：所有引用该表的存储过程在下一次执行前均需重编译。

第3步：清除 Plan Cache 的操作

某些管理操作会清除整个服务器或部分数据库的执行计划缓存，迫使所有相关语句重新编译：

全局清除：分离数据库（Detach）、数据库升级迁移至新服务器、运行 DBCC FREEPROCACHE、执行 RECONFIGURE 语句、修改数据库字符集（Collation）等。
特定数据库清除：执行 DBCC FLUSHPROCINDB（需在 SQL Server 2000 兼容模式下使用，现代版本通常用 DBCC FREEPROCACHE 代替全局清理或通过 ALTER DATABASE 切换状态）。具体示例如下：

DECLARE @a INT;
SELECT @a = DB_ID('gposdb');
DBCC FLUSHPROCINDB (@a); -- 仅用于特定数据库，注意版本兼容性

此外，数据库名称修改（ALTER DATABASE MODIFY NAME）、在线/离线切换（ONLINE/OFFLINE）、紧急模式（EMERGENCY）、删除数据库、数据库自动关闭、CHECKDB 结束时等操作均会触发对应范围的缓存清理。

第4步：SET 开关值的变化

如果执行会话中的 SET 选项配置发生变化，先前缓存的执行计划将不可重用。这主要因为某些 SET 值会影响查询逻辑或结果。涉及的关键选项包括：

Ansi 相关：ansi_null_dflt_off/on, ansi_nulls, _ansi_padding, ansi_warnings
其他控制：arithabort, concat_null_yields_null, datefirst, dateformat, forceplan, language, no_browsetable, numeric_roundabort, quoted_identifier

第5步：统计信息（Statistics）更新

当表的统计信息被手动更新，或者 SQL Server 的后台代理检测到统计信息陈旧需自动更新时，涉及该表的所有语句在运行时都会触发重编译，以确保基于最新的数据分布生成计划。

总结

在 SQL Server 中，编译与重编译并非绝对的“好”或“坏”。适度的重用节省了资源，而必要的重编译保证了准确性。大多数情况下，SQL Server 引擎能很好地平衡这两者。DBA 和开发人员应重点关注由“参数嗅探”引起的长查询变慢问题，通过适当的重编译策略（如 OPTIMIZE FOR 提示、局部变量隔离等）来优化性能。

以上就是 SQL Server 编译与重编译原理及触发条件的详细内容，更多关于数据库性能调优与维护的资料请关注本站其它相关文章！