sql server夜间性能差主因是统计信息未及时更新，需在etl后立即执行update statistics with fullscan，并结合参数嗅探问题同步验证执行计划估算行数与实际行数是否接近。
夜间执行慢，先查是不是统计信息没更新
SQL Server 默认的 AUTO_UPDATE_STATISTICS 触发条件太“懒”：表里约 20% 行被修改才更新。对夜间批量导入的大表（比如 ETL 加载千万级订单），这个阈值根本等不到——导入完成时统计还是旧的，第一次调用存储过程就只能靠猜，结果生成全表扫描计划。
常见错误现象：sys.dm_db_stats_properties 查到 last_updated 是昨天甚至上周，modification_counter 却高达几十万；执行计划里出现高占比的 Table Scan 或 Clustered Index Scan，但 WHERE 条件字段明明有索引。
- 对刚加载完的大表，立刻跑
UPDATE STATISTICS 表名 WITH FULLSCAN，别等自动更新 - 避免在存储过程中加
WITH RECOMPILE掩盖问题——它只解决单次编译，不修复统计陈旧这个根因 - 如果 JOB 里用了
sp_updatestats，注意它默认跳过user_created统计以外的统计，且不保证 FULLSCAN；更稳妥的是显式指定表+采样率
索引维护 JOB 和统计更新 JOB 别混在一起跑
索引重建（ALTER INDEX ... REBUILD）会自动触发统计更新，但仅限于该索引列上的统计；而 UPDATE STATISTICS 不会影响索引物理结构。两者目标不同，强行合并容易出事。
典型翻车场景：JOB 里先 REBUILD 索引，再跑 sp_updatestats，结果后者又把刚建好的统计覆盖成低采样率版本；或者两个 JOB 同时跑，争抢 tempdb 资源，导致 I/O 阻塞。
- 索引维护 JOB 专注碎片整理：页密度 30% 的索引才重建，其余用
REORGANIZE - 统计更新 JOB 单独调度，和 ETL 完成时间强绑定（比如 ETL 结束后 2 分钟内启动），不依赖索引维护节奏
- 对关键业务表，用
CREATE STATISTICS显式建单列统计（如WHERE status = 'N'），并配WITH FULLSCAN，别指望sp_updatestats自动覆盖
参数嗅探 + 陈旧统计 = 夜间雪崩组合拳
存储过程第一次用小参数（如 @order_id = 123）编译，生成嵌套循环计划；但夜间跑的是大数据集（@date_from = '2024-01-01'），优化器却还在用旧统计估算行数，误判嵌套循环比哈希连接快，结果 CPU 拉满、内存溢出。
这时候光看单次执行计划没用——图形里可能显示 Hash Match 占比 85%，但你得结合 sys.dm_exec_query_stats 查历史平均逻辑读：如果 avg_logical_reads 波动极大（比如白天 1000，夜间 200 万），基本就是参数+统计双重失效。
- 优先修复统计：确认
last_updated和数据变更时间匹配，再考虑加OPTIMIZE FOR (@param = value) - 慎用
WITH RECOMPILE：它让每次执行都重编译，对高频调用的存储过程反而加重 CPU 压力 - 临时方案可加
OPTION (RECOMPILE)在问题语句末尾，但必须配合监控——它只是止血，不是缝合
检查统计是否真生效，别信“已更新”三个字
DBA 执行完 UPDATE STATISTICS 就说“搞定了”，但开发看到执行计划还是扫表——因为统计对象名可能和你想象的不一样。SQL Server 对没有显式命名的统计，会自动生成类似 _WA_Sys_00000003_12345678 这种名字，sp_updatestats 可能漏掉它。
验证方法很简单：在 SSMS 里右键表 → “属性” → “统计信息”，看列表里有没有对应列的条目；或者直接查 sys.stats，确认 name 和 object_id 匹配你要查的字段。
- 用
DBCC SHOW_STATISTICS (表名, 统计名)看直方图步长，确认RANGE_HI_KEY是否包含你查询的值范围 - 如果发现统计名是系统生成的，下次建索引时加
WITH STATISTICS_NORECOMPUTE = OFF，避免它被自动关掉 - 对多列组合谓词（如
WHERE status = 'Y' AND created_at > '2024-01-01'），必须建复合统计，单列统计不管用
Estimated Number of Rows 和真实返回行数是否接近。差十倍以上，说明统计或参数至少有一个没对齐。
