SQL Server中简单UPDATE语句首次执行超慢，后续极速的原因排查

场景回顾 #

执行的SQL语句：

UPDATE [BasicUserTable] 
SET [DateTimeCol] = '9/6/2022'
WHERE [UniqueIntPKCol] = 123

• 表规模：不足10000条记录，主键为自增INT类型
• 现象：首次执行耗时1分30秒（触发应用30秒超时），后续仅修改ID和日期的同结构语句耗时均<100ms；SSMS手动执行首次同样慢，后续恢复正常
• 排查现状：未发现阻塞锁日志、SQL错误日志无异常

可能原因与排查/解决方法 #

• 缓冲区缓存预热
  SQL Server首次访问数据时，需要将目标数据页、主键索引页从磁盘加载到内存缓冲区（Buffer Pool），这个磁盘IO过程耗时较长。后续执行直接读取内存缓存，速度骤升。如果服务器内存不足，或该表长期未被访问，就会出现此情况。可通过重启SQL Server后再次测试验证（重启会清空缓冲区）。

• 索引碎片或统计信息过期
  即便主键是自增INT，若表经历过大量增删改，主键索引可能产生碎片，导致首次查找需遍历更多磁盘页；另外，过期的统计信息会让查询优化器生成低效执行计划，首次执行踩坑，后续计划缓存或统计信息自动更新后恢复正常。

  • 更新统计信息：

    UPDATE STATISTICS [BasicUserTable];
    

  • 检查索引碎片：

    SELECT index_id, index_type_desc, avg_fragmentation_in_percent 
    FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('BasicUserTable'), NULL, NULL, 'DETAILED');
    

  • 碎片率超过30%时重建主键索引：

    ALTER INDEX PK_BasicUserTable_UniqueIntPKCol ON [BasicUserTable] REBUILD;
    

• 隐性锁等待或行版本延迟
  虽然日志未显式记录阻塞，但可能存在隐性锁等待（如之前未提交的事务残留锁、快照隔离下的行版本清理延迟），首次执行时触发等待，后续锁释放或行版本清理完成后恢复。可在慢查询执行时实时查看等待类型：

  SELECT session_id, wait_type, wait_time_ms 
  FROM sys.dm_exec_requests WHERE session_id = @@SPID;
  

• 自动维护任务冲突
  首次执行恰好撞上SQL Server自动维护任务（如索引重建、统计更新、备份），这些任务占用大量磁盘IO/CPU，导致查询卡顿。后续维护任务结束后资源释放，速度恢复。可核对维护计划的执行时间点是否与首次慢查询时间匹配。

• EF Core首次执行初始化开销
  应用首次执行该UPDATE时，EF Core需完成模型映射、SQL语句生成、查询计划编译等初始化工作，叠加SQL Server的磁盘IO耗时，总时长超过30秒超时阈值。后续执行时EF Core已缓存相关信息，仅执行SQL逻辑，速度提升。可在应用启动阶段预热相关查询（如提前执行一次无实际修改的查询）规避超时。

内容的提问来源于stack exchange，提问作者Zambodi