存储过程本身不提速，真正起作用的是执行计划复用、参数化方式、索引匹配和避免隐式转换；性能问题多源于写法不当或调用方式错误。
直接上结论：存储过程本身不提速，真正起作用的是执行计划复用、参数化方式、索引匹配和避免隐式转换。很多团队以为“改成存储过程就快了”，结果发现性能没变化甚至更差——问题往往出在写法和调用方式上。
为什么存储过程在百万级数据下可能变慢
SQL Server 的存储过程确实有预编译优势，但这个优势只在「执行计划能被复用」时才生效。一旦出现以下情况，缓存计划就会失效或被绕过：
-
WITH RECOMPILE被显式加上，每次执行都强制重编译 - 参数类型与列类型不一致（比如
@id INT传给id VARCHAR(20)字段），触发隐式转换，导致索引失效 - 动态拼接 SQL（
EXEC(@sql)）完全脱离计划缓存体系 - 表结构变更（如加索引、改字段类型）后，旧计划被标记为无效，首次执行又得编译
必须检查的 WHERE 条件写法
百万级数据下，90% 的慢查询根源在 WHERE 子句破坏了索引使用。常见陷阱包括：
- 别在索引列上做函数：把
WHERE YEAR(createdate) = 2025改成WHERE createdate >= '2025-01-01' AND createdate - 避免
OR连接不同索引字段：如WHERE status = 1 OR type = 'A'，优先拆成UNION ALL或用EXISTS -
IN列表超过 200 项时，SQL Server 可能放弃使用索引；改用临时表 +JOIN更稳 - 参数化查询中，确保变量类型与目标列完全一致：
DECLARE @order_id BIGINT对应order_id BIGINT列，而不是INT
分页逻辑必须避开 OFFSET FETCH 的坑
SQL Server 2012+ 的 OFFSET ... FETCH 在大数据偏移时性能断崖式下跌（比如 OFFSET 100000 ROWS）。真实场景中，它会扫描前 10 万行再丢弃。
- 替代方案是「游标分页」：记录上一页最后的
id值，下一页查WHERE id > @last_id ORDER BY id ASC LIMIT 100 - 如果排序字段非唯一，组合主键字段补全：如
ORDER BY createdate, id，条件写成WHERE (createdate > @last_date) OR (createdate = @last_date AND id > @last_id) - 千万别在存储过程中用
SELECT TOP (@n) ... ORDER BY ... OFFSET @offset ROWS做通用分页——参数化 offset 会让优化器无法生成稳定计划
容易被忽略的统计信息和执行计划细节
即使写了正确的 SQL，如果统计信息过期或执行计划选错索引，照样慢。关键动作要手动做：
- 定期更新统计信息：
UPDATE STATISTICS dbo.orders WITH FULLSCAN, NORECOMPUTE（对百万级表，FULLSCAN比默认采样更可靠） - 用
SET STATISTICS XML ON看实际执行计划，重点看「实际行数 vs 预估行数」是否偏差巨大（>5 倍即危险） - 留意警告图标：比如 “Missing Index” 提示，或 “Table Scan” 出现在本该走索引的地方
- 如果某次执行突然变慢，先查
sys.dm_exec_query_stats，看是不是用了低效的旧计划；可用sp_recompile强制刷新
最麻烦的不是写不出快 SQL，而是同一个存储过程，在测试库飞快、上线后却持续 8 秒——往往是因为生产环境的数据分布、并发压力、内存压力让优化器选了另一条路。所以不要只信“本地跑得通”，一定要在准生产数据量+真实并发下压测执行计划稳定性。
