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