在数据库日常使用中，不少人遇到过这样的情况：一个SQL存储过程刚创建完第一次执行花了好几秒，可再次调用时瞬间就返回了结果。这并非数据变少了，而是数据库的执行计划缓存机制在发挥作用。了解它为什么能让存储过程变快，以及怎么利用它做优化，对提升系统性能很关键。
执行计划缓存是什么
当数据库收到存储过程执行请求时，首先要做语法解析和语义检查，然后通过优化器计算最优的数据访问路径，生成执行计划，最后编译成可执行代码。首次运行经历的完整解析、优化、编译过程叫作硬解析。数据库会把这次生成的执行计划以特定键值为标识，保存在内存的缓存区域里，这就是执行计划缓存。
为什么首次慢而后续快
首次运行必须完成硬解析，优化器要评估索引、统计信息、连接顺序等，CPU和内存开销大。执行计划进入缓存后，后续相同存储过程调用只需要做软解析：通过标识在缓存里找到已有计划，验证有效性后直接执行，跳过了最耗时的优化与编译阶段，所以响应时间大幅下降。
影响缓存命中的常见因素
- 存储过程语句中包含非参数化的动态拼接，导致每次文本不同
- 统计信息更新后，旧计划被标记为失效并重编译
- 缓存内存不足，旧计划被数据库自动清理
- 使用了 WITH RECOMPILE 选项强制每次重编译
如何利用缓存机制提高性能
要让存储过程稳定命中缓存，核心思路是保持执行计划稳定且可被复用。推荐做法包括使用参数化查询、避免存储过程内随意拼接SQL、合理更新统计信息以及控制重编译时机。
使用参数化避免硬解析
下面示例展示了一个简单的参数化存储过程，它通过输入参数查询订单，数据库只需为这个存储过程缓存一份计划：
CREATE PROCEDURE GetOrderByUser
@userId INT
AS
BEGIN
SELECT order_id, amount, create_time
FROM orders
WHERE user_id = @userId;
END;
如果改为在存储过程里用字符串拼接再 EXEC，那么不同 userId 会生成不同语句文本，缓存难以复用。
查看缓存命中情况
在 SQL Server 中，可以通过系统视图观察缓存的执行计划和使用次数：
SELECT objtype, usecounts, text FROM sys.dm_exec_cached_plans cp CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) WHERE text LIKE '%GetOrderByUser%';
若 usecounts 数值持续增长，说明该存储过程一直在复用缓存计划，性能表现会较平稳。
需要注意的误区
有人为了快而给所有存储过程加 KEEPFIXED PLAN 或禁用重编译，但统计信息大幅变化后老计划可能变低效。正确做法是根据业务数据变更频率，平衡缓存复用与计划准确性。对于频繁变更筛选条件的报表类需求，可考虑用临时表分步处理，减少单一语句的优化复杂度。
| 场景 | 建议方式 |
|---|---|
| 高频固定条件查询 | 参数化存储过程，依赖缓存 |
| 低频复杂报表 | 允许按需重编译保证计划正确 |
| 数据分布突变 | 更新统计信息触发软重编译 |
合理利用执行计划缓存，是低成本提升SQL存储过程性能的重要手段。写好参数化语句、关注缓存命中率，就能让数据库跑得更顺。