SQL Server统计信息需动态维护以保障查询性能。应根据数据变更频率选择自动或手动更新，合理设置采样率，聚焦关键列创建统计，并通过监控与自动化确保及时更新。
SQL 数据库的统计信息是查询优化器生成高效执行计划的基础。统计信息过时或缺失，会导致优化器误判数据分布，选择低效索引、错误连接方式，甚至全表扫描，显著拖慢查询性能。维护好统计信息不是“一劳永逸”的任务，而需结合数据变更频率、查询模式和数据库版本特性动态调整。
自动更新是否足够？关键看数据变动规模
SQL Server 默认启用
AUTO_UPDATE_STATISTICS
，但它的触发阈值较保守：当表中约 20% 的行被修改（对大表来说可能高达数百万行），才会触发更新。这意味着小批量高频插入/删除/更新（如每分钟几千条日志）可能长期不触发更新，导致统计滞后。
对写入频繁但单次量小的表（如订单明细、操作日志），建议关闭自动更新，改用定时作业手动更新，例如每15–30分钟执行一次
对夜间批量导入的大表（如ETL后），务必在加载完成后立即运行
，避免首次查询时因统计陈旧引发严重性能抖动
可通过查询
检查最后更新时间与修改行数，识别“高危”统计对象
采样率不是越高越好，要权衡精度与开销
默认采样率由SQL Server自动估算，通常在1–20%之间。FULLSCAN 精度最高但代价极大，尤其对TB级表可能耗时数分钟并阻塞部分操作；低采样率（如1%）速度快，但面对倾斜数据（如90%用户来自3个省份）容易失真。
数据分布均匀（如自增ID主键、时间戳字段）：5–10% 采样已足够可靠
存在明显倾斜（如状态码只有'Y'/'N'，但99%为'Y'）：优先对关键谓词列（如
）创建带
的单列统计，或使用
避免对宽文本列（如
）建统计——既无意义又拖慢更新
聚焦关键列，别给所有字段“平均用力”
统计信息本质是列值分布的直方图+密度向量。优化器只关心 WHERE、JOIN、ORDER BY、GROUP BY 中出现的列。盲目为所有列建统计不仅浪费存储和更新时间，还可能干扰优化器选择（过多统计增加决策复杂度）。
优先保障：主键、外键、高频过滤条件列（如
）、多列组合筛选列（如
）
慎用：NULL值占比极高（>95%）的列、低基数且极少用于过滤的列（如性别字段仅2值且从不在WHERE中出现）
可用
查看直方图步长（Steps），若步数<20且数据量>10万，说明当前统计粒度太粗，考虑重采样
监控与自动化：让维护变成可追踪的例行动作
靠人工检查不现实。应建立轻量级监控机制，把统计健康度纳入日常巡检。
每日跑一次脚本，列出
且
的统计项，邮件预警
对核心业务表，将
加入部署流程：应用发布前先更新相关表统计，防止新SQL因统计未生效而走错执行计划
SQL Server 2016+ 可启用
ASYNC_STATS_UPDATE
，让统计更新异步进行，避免查询被阻塞（注意：异步更新期间优化器仍用旧统计）
统计信息本身不消耗查询资源，但它的质量直接决定执行计划优劣。与其花几小时调优一条慢SQL，不如花十分钟确认它的统计是否新鲜、准确、聚焦。这不是高级技巧，而是数据库稳定运行的基本功。
UPDATE STATISTICS 表名 WITH SAMPLE 30 PERCENTUPDATE STATISTICS 表名 WITH FULLSCANsys.dm_db_stats_propertiesWHERE status = 'N'WITH FULLSCANCREATE STATISTICS ... WITH SAMPLE 100 PERCENTvarchar(max)order_date > '2024-01-01'(status, priority)DBCC SHOW_STATISTICS (表名, 统计名)stats_date < GETDATE()-1modification_counter > 0UPDATE STATISTICS