不能靠“等自动更新”，必须结合手动干预+计划控制，否则慢查会反复出现；应通过STATS_DATE查超7天未更新统计信息，再用实际执行计划中EstimateRows与ActualRows差一个数量级交叉验证，辅以DBCC SHOW_STATISTICS检查Modification Counter是否≥Rows Sampled×0.2。
直接结论：不能靠“等自动更新”，必须结合手动干预 + 计划控制，否则慢查会反复出现，尤其在数据批量导入、分区切换或参数跨度大的场景下。
怎么快速确认是统计信息过时导致的慢查
别猜，用两个命令交叉验证：
- 查统计信息最后更新时间：
STATS_DATE(object_id, stats_id)，配合sys.stats和sys.tables连查，筛选超过 7 天未更新的项 - 查执行计划里的关键偏差：开启
SET STATISTICS XML ON，找EstimateRows和ActualRows，差一个数量级（比如预估 100 行、实际 12000 行）基本可锁定 - 补充验证：运行
DBCC SHOW_STATISTICS('table_name', 'stats_name')，重点看Modification Counter是否 ≥Rows Sampled × 0.2
UPDATE STATISTICS 怎么写才不翻车
全库刷 sp_updatestats 是懒人做法，对大表无效、对临时表没用、对分区表漏更新。实操按优先级来：
- 对关键业务表（如日增千万级的订单表）：用
UPDATE STATISTICS table_name WITH FULLSCAN, COLUMNS，强制全量扫描并更新列级直方图 - 对超大表（比如 5 亿行以上）：改用
WITH SAMPLE 30 PERCENT，避免长时间阻塞，精度损失可控 - 对分区表：必须显式指定分区，例如
UPDATE STATISTICS Orders ON IX_OrderDate WITH RESAMPLE ON PARTITIONS(5) - 对临时表：
INSERT INTO #temp后立刻跟UPDATE STATISTICS #temp，否则优化器完全瞎猜
为什么更新完还是慢？可能是参数嗅探在捣鬼
统计信息只是“眼睛”，而参数嗅探会让优化器“看错人”。典型表现是：同一存储过程，传 @date = '2026-01-01' 很快，传 @date = '2026-10-20' 就卡死——因为首次编译用了小范围值生成了嵌套循环计划，后续大数据量复用就崩了。
- 轻量解法：
OPTION (OPTIMIZE FOR UNKNOWN)，让优化器忽略具体值，按平均分布估算（适合参数无明显倾斜） - 精准解法：
OPTION (RECOMPILE)，每次执行都重编译（适合时间范围跨度从 1 天到 3 年这种极端场景） - 慎用解法：
WITH RECOMPILE创建存储过程，整过程每次调用都重编译（高频 SP 会导致 CPU 暴涨） - 绝对要避开：
DBCC FREEPROCCACHE，它清的是全局缓存，影响所有查询，不是治病，是放血
容易被忽略的复合陷阱
真实生产环境里，慢查很少由单一原因引起。以下三点常被跳过，但一碰就卡：
- 动态 SQL（
EXEC(@sql)或sp_executesql）完全绕过计划缓存，统计信息更新对它无效，必须加OPTION (RECOMPILE)才能生效 - 连接级
SET选项不同（比如一个连ARITHABORT ON，另一个没设），SQL Server 视为两个独立上下文，各自缓存计划——看起来像“刚更新完统计信息却没用” - 参数值极端偏斜（如
@customer_id = 999999只有 1 条记录）生成的计划，后续传入主流 ID（10 万条）必然失准，这时光更新统计信息没用，得用OPTIMIZE FOR (@customer_id = 100)强制参考值
