索引存在不等于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 日志、生成 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 的执行计划和运行时指标，比盲目添加索引或修改语句更为有效。