应通过DBCC SHOW_STATISTICS查看Rows Sampled与Modification Counter，若后者接近或超前者20%即判定严重滞后；再结合实际执行计划中EstimateRows与ActualRows差异是否超一个数量级来验证。
怎么确认统计信息是不是过期了
不能光看执行慢就猜是统计信息问题，得用数据说话。重点查 DBCC SHOW_STATISTICS 的输出里两个字段：Rows Sampled 和 Modification Counter。前者表示上次采样了多少行，后者表示自采样后有多少行被修改过。如果 Modification Counter 接近或超过 Rows Sampled 的 20%，基本可以判定统计信息严重滞后。
更直接的办法是对比预估行数和实际行数：打开实际执行计划（SET STATISTICS XML ON），找 EstimateRows 和 ActualRows 差异是否超过一个数量级。差得越多，统计信息越不可信。
手动更新统计信息的实操要点
别一上来就 sp_updatestats 全库刷——它只更新“有变化”的表，且采样率固定，对大表效果差。优先按需更新：
- 对关键业务表，用
UPDATE STATISTICS table_name WITH FULLSCAN, COLUMNS强制全量扫描并更新列统计 - 对超大表（比如上亿行），用
WITH SAMPLE 30 PERCENT平衡精度和耗时，避免阻塞 - 更新完立刻执行一次存储过程，观察
plan_generation_num是否归零（查sys.dm_exec_query_stats），确认新计划已生效
自动收集策略容易踩的坑
SQL Server 自动更新默认开启，但有两个隐蔽陷阱：
- 自动更新只在查询编译时触发，且依赖
Auto Update Statistics和Auto Update Statistics Asynchronously两个开关。后者设为ON会导致计划先用旧统计跑一次，再异步更新——这就是为什么“刚改完数据，第一次查还是慢” - 分区表的统计信息不会自动跨分区更新，必须显式指定分区号，例如
UPDATE STATISTICS Orders ON IX_OrderDate WITH RESAMPLE ON PARTITIONS(3) - 临时表的统计信息永远不会自动更新，所有涉及临时表的查询，必须在
INSERT后手动加UPDATE STATISTICS #temp_table
统计信息之外的干扰项要同步排查
统计信息只是执行计划失准的常见原因，不是唯一原因。遇到更新后仍慢，立刻检查：
- 存储过程中有没有
EXEC(@sql)或sp_executesql动态拼接？这类语句完全绕过计划缓存，每次都是全新编译 - 调用方是否设置了不同
SET选项？比如一个连接用SET ARITHABORT ON，另一个没设，SQL Server 视为两个独立上下文，各自缓存计划 - 参数值是否极端偏斜？比如首次传入
@customer_id = 999999（只有一条记录），生成嵌套循环计划并缓存，后续传入主流客户ID就崩
统计信息更新本身很快，但真正难的是判断“该不该更新”“更新哪几张表”“更新后计划是否真的换了”。很多团队卡在这一步，不是不会操作，而是没把执行计划、参数值、调用链路串起来看。
