UPDATE索引列本身不慢，慢在触发非聚集索引逐项重写、页分裂、锁竞争及统计信息与执行计划滞后；优化应精简非聚集索引、避免实时更新索引键列、必要时改用异步刷新。
UPDATE 带索引的列本身不慢，慢在它触发了索引结构的连锁更新——尤其是非聚集索引（二级索引）的逐项重写、页分裂和锁竞争。这不是“改一列”的操作，而是“改一行 + 同步刷新所有相关索引项 + 可能触发统计信息失效 + 计划缓存未刷新”的叠加效应。
为什么UPDATE索引列会引发非聚集索引全量重写
只要被修改的列出现在任一非聚集索引的键列（key column）或包含列（included column）中，该索引对应的所有叶级条目就必须重写。
-
UPDATE users SET email = 'new@x.com' WHERE id = 123——若email是某个非聚集索引的键列，则该索引中所有id = 123对应的索引行都要从旧值挪到新位置（B+树重平衡），哪怕只改一个字节 - 若该索引还有
INCLUDE (status, created_at)，而status或created_at也被同时更新（如SET email = ..., status = 'active'），则整条索引记录必须重建 - 对比：仅更新未被任何非聚集索引覆盖的列（如
notes字段），则只有聚集索引（或堆）需更新，非聚集索引完全不动
执行计划退化：统计信息陈旧 + 索引碎片叠加
高频更新索引列后，sys.dm_db_index_usage_stats 中的 user_updates 会飙升，但 user_seeks 可能很低——说明索引正在被“拖累”而非“服务”。此时两个隐性问题常同时发生：
- 统计信息未自动更新：即使
AUTO_UPDATE_STATISTICS = ON，默认阈值是“表中 20% 行变动”，小表或低频更新场景下长期不触发；手动补一句UPDATE STATISTICS users (IX_users_email)很必要 - 索引碎片快速堆积：频繁更新导致页分裂，
avg_fragmentation_in_percent在几天内就可能从 5% 涨到 40%+；用sys.dm_db_index_physical_stats查，别等用户报慢 - 执行计划缓存未刷新：存储过程编译时基于旧统计信息生成计划，重建索引后不执行
sp_recompile 'YourProcName'，它仍沿用“扫描 50 万行”的旧计划
锁与日志开销被显著放大
更新索引列不只是数据页变更，它直接拉高事务粒度和日志体积：
- 每条非聚集索引更新都需获取
KEY或INDEX KEY锁，多索引并发更新易出现LCK_M_U等待；比只更新聚集索引多出 N 倍锁申请次数（N = 相关非聚集索引数） - 每个索引项重写都会产生独立的
LOP_INSERT_ROWS/LOP_DELETE_ROWS日志记录；1 行更新 3 个非聚集索引 ≈ 生成 6 条日志，redo log写入压力陡增 - MySQL InnoDB 下，
innodb_row_lock_waits持续上涨、SHOW PROCESSLIST中大量Updating状态卡住，基本可锁定为索引列高频更新引发的锁争用
什么时候必须更新索引列？怎么减缓影响
不是“能不能”，而是“不加就跑不动”。典型场景是该字段虽常更新，但更是高频查询条件，且没有其他过滤性更强的字段可用。例如订单表的 status 字段，每笔支付成功都要 UPDATE status='paid'，但运营后台又频繁执行 SELECT * FROM orders WHERE status='shipped' AND created_at > '2024-01-01'。
- 务必用
EXPLAIN验证：不加索引时是否走了type=all，加了之后是否变成ref或range - 避免冗余：如果已有联合索引
(status, created_at)，就别再单独建INDEX(status) - 高频更新字段优先用
CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP自动更新，减少 SQL 层显式赋值 - 把高频更新字段和低频查询字段拆到不同索引中：别把
updated_at和常用于WHERE的status绑死在一个复合索引里
最常被忽略的是：索引维护成本不是线性的，而是随索引数量呈倍数增长；一次 UPDATE 触发 5 个非聚集索引重写，实际 I/O 和锁开销可能接近 5 次独立更新。优化前先查 sys.dm_db_index_usage_stats 或 information_schema.STATISTICS，确认哪些索引真正在被查询使用，而不是凭感觉保留。
