SQL报表执行计划异常主因是统计信息过期或缺失；更新需兼顾准确、稳定、省资源，优先覆盖高频查询大表、变更剧烈表、主外键及倾斜列，并针对新分区手动更新。
SQL报表执行计划异常，往往不是SQL写得有问题，而是优化器“看错了”数据分布——统计信息过期或缺失是最常见原因。更新统计信息不是越频繁越好，也不是全库一键更新就万事大吉，关键在“准、稳、省”：准确反映数据变化、稳定避免计划抖动、节省维护开销。
哪些表/列必须优先更新统计信息
重点盯住高频查询、大表、数据变更剧烈的表，尤其是WHERE、JOIN、ORDER BY中用到的列：
- 行数增长超20%或删除超15%的表（如日志表、订单表）
- 主键、外键、组合索引首列（这些列直接影响连接顺序和索引选择）
- 业务上有明显倾斜的列（如status=‘已支付’占95%，但查询常查‘待审核’）——这种场景需启用列级直方图
- 分区表中刚切换的新分区（老分区若无变更可跳过）
自动更新够用吗？什么时候要手动干预
SQL Server默认开启AUTO_UPDATE_STATISTICS，但有明显延迟和盲区：
- 只在查询编译时触发，且要求“修改行数 > (表总行数 × 阈值)”，小表（
- 不覆盖列级统计（如CREATE STATISTICS on colA, colB），仅更新索引列或单列统计
- 大批量ETL后立即查报表，自动更新来不及触发，必须在作业末尾加UPDATE STATISTICS
- 发现执行计划突变（如索引查找变成全表扫描）、逻辑读飙升，先检查sys.dm_db_stats_properties确认last_updated和modification_counter
更新策略怎么定才稳妥
按表分级管理，避免“一刀切”：
- 核心交易表（如orders、users）：每日凌晨低峰期，用SAMPLE 30 PERCENT + NORECOMPUTE（防自动干扰），并指定COLUMNS（只更新关键列统计）
- 维表/配置表（如product_category）：变更极少，每月检查一次，有更新再执行FULLSCAN
- 临时分析表/中间表：插入完成后立刻UPDATE STATISTICS WITH FULLSCAN，不依赖自动机制
- 超大历史分区表：只更新活跃分区（如最近3个月），用ON PARTITIONS语法，跳过冷数据
验证效果比执行更重要
更新完别急着上线报表，三步确认是否真解决问题：
- 用DBCC SHOW_STATISTICS查看density vector和histogram，确认distinct value、range_rows是否符合预期
- 执行SET STATISTICS XML ON，对比更新前后实际执行计划，重点关注Estimated Rows vs Actual Rows偏差是否缩小
- 在测试环境用相同参数重跑慢报表，观察CPU/IO/Duration变化，而非只看“走了哪个索引”
