为什么我的SQL UPDATE语句已有索引却执行缓慢 该如何排查

索引存在不等于UPDATE性能达标，关键在于执行计划是否触发宽计划、非聚集索引是否必要更新、WHERE/SET是否导致索引失效、统计信息是否准确、锁与事务配置是否合理。

索引用了但UPDATE还是慢，大概率不是“有没有索引”的问题，而是“怎么用”和“用得多不多”的问题。尤其当涉及多个非聚集索引、大范围更新或锁争用时，索引存在 ≠ 性能达标。

查执行计划里是不是窄计划在扛大压力

SQL Server 对 UPDATE 会选窄计划或宽计划。窄计划（per-row update）逐行更新所有索引，I/O 随机性高；宽计划（per-index update）先排序再批量刷索引页，更省 I/O。但宽计划有硬门槛：

• 影响行数必须 > 250
• 非聚集索引总大小（叶级页数 × 8 KB）≥ max server memory 的 1/1000

如果实际更新了 300 行，但非聚集索引加起来才 1 MB，而 max server memory 是 16 GB，那宽计划直接被跳过——你看到的执行计划里 Update 算子下面全是嵌套的 Index Seek + Clustered Index Update，这就是窄计划在反复随机寻道。用 SET STATISTICS XML ON 跑一次，看是否出现 Wide 字样；没有，就说明没触发宽计划。

确认非聚集索引是否真的需要全更新

UPDATE 某列时，只有被修改的列所在的非聚集索引才需要更新。但如果 WHERE 条件里用了函数、类型转换，或 SET 子句里对索引列做了计算（比如 SET status = status + 1），可能导致本该走 seek 的操作退化成 scan，连带拖垮所有关联索引的更新路径。

• 检查 WHERE 是否对索引列用了 UPPER()、DATE()、隐式转换（如 varchar 字段跟数字比较）
• 检查 SET 是否修改了非聚集索引的键列或包含列；哪怕只改一个字节，整个索引项也要重写
• 用 sys.dm_db_index_usage_stats 查 user_updates，对比各索引更新频次——如果某个非聚集索引 user_updates 远高于 user_seeks，说明它正在被频繁拖累却几乎不用

盯住 rows_examined 和锁等待时间

MySQL 下看慢日志里的 Rows_examined，SQL Server 下看执行计划的 Actual Number of Rows 输出。如果 UPDATE 本该改 100 行，却扫描了 50 万行，说明 WHERE 条件没走对索引，或者统计信息陈旧导致优化器误判。

• 运行 UPDATE STATISTICS 强制刷新统计信息，尤其在大批量 INSERT/DELETE 后
• 检查是否因 OR、IN 列表过大、LIKE '%abc' 导致索引失效
• 用 sp_who2 或 sys.dm_exec_requests 查 blocking_session_id 和 wait_type；常见阻塞源是 LCK_M_U（等待更新锁）或 PAGELATCH_UP（内存页争用）

别忽略事务隔离级别和日志写入开销

UPDATE 不只是改数据，还要写 redo log、生成 undo、维护 MVCC 版本。高隔离级别（如 SERIALIZABLE）或长事务会让锁持有时间拉长，间接拖慢后续 UPDATE。

• 确认事务是否包裹了无关操作（比如在 UPDATE 前调用外部 API 或做大量计算）
• 检查 innodb_log_file_size（MySQL）或 recovery interval（SQL Server）是否过小，导致频繁 checkpoint 或 log flush
• 批量 UPDATE 时，避免单条语句更新几万行；拆成每批 1000–5000 行，配合 WAITFOR DELAY '00:00:00.01' 减轻锁竞争

真正卡住的地方，往往不在 SQL 写法本身，而在索引更新的物理代价、锁的传播路径、或是统计信息和内存配置之间的错配。动手前先抓一条真实慢 UPDATE 的执行计划和运行时指标，比盲目加索引或改语句更有效。