UPDATE索引列会触发所有相关索引重写，包括二级索引更新、唯一性校验、锁范围扩大及日志写入等四重开销；高频更新字段不应与查询字段强耦合，避免隐式转换和大事务批量更新。

UPDATE索引列会触发所有相关索引重写

只要被修改的列出现在任意一个非聚集索引（二级索引）的键列或包含列中，InnoDB就必须重写该索引项。哪怕只改了一个字节，整个索引页里的对应条目就要更新、可能分裂、还要刷盘。如果一张表有5个二级索引，UPDATE一条记录就等于执行5次索引维护操作。

常见错误场景：

• UPDATE users SET status = 'active', updated_at = NOW() WHERE id = 123 —— 若status和updated_at共同构成复合索引idx_status_updated，这次更新必然触发该索引重建
• 把高频更新字段（如view_count、last_seen）和查询字段（如tenant_id）强行塞进同一个联合索引，导致每次访问都连带更新

唯一索引校验带来额外I/O与CPU开销

每个UNIQUE INDEX在UPDATE涉及索引列时，都会触发一次B+树查找，用于确认修改后是否仍满足唯一性约束。这不是“顺便检查”，而是强制同步阻塞步骤——即使你只是把email从a@b.com改成A@b.com，数据库也得先查一遍有没有其他行已经是A@b.com。

实操建议：

• 避免在UPDATE语句中无谓修改唯一索引列：用WHERE email != 'A@b.com'提前过滤，防止空更新触发校验
• 不要为低基数字段（如gender、is_deleted）建唯一索引——它既不提升查询选择性，又白增写入负担
• 联合唯一索引中含NULL列时注意行为：MySQL允许(1, NULL)和(1, NULL)共存，但一旦两列都非NULL，校验就会严格执行

隐式类型转换让索引失效，进而扩大锁范围

当WHERE条件里发生隐式转换（比如user_id是BIGINT，却写成WHERE user_id = '123'），优化器无法使用索引定位，被迫全表扫描。这时UPDATE不再只锁几行，而是对所有行加next-key lock——等于锁住整张表，直到事务结束。

更隐蔽的问题是：这类转换常发生在应用层拼SQL或ORM未严格绑定参数类型时，执行计划里type显示ALL或index，key为空，rows_examined远高于预期。

验证方式：

• MySQL下用EXPLAIN FORMAT=TRADITIONAL看key是否为NULL，rows是否异常高
• SQL Server下查sys.dm_exec_query_stats中total_logical_reads突增，同时execution_plan里出现Table Scan
• PostgreSQL必须显式报错或拒绝，若没报错，说明collation配置允许隐式转换，更要警惕

批量UPDATE没分片会引发锁升级与日志风暴

一条UPDATE orders SET status = 'shipped' WHERE created_at 若匹配80万行，在未加LIMIT且无分批次控制时，InnoDB会尝试一次性持有80万个行锁。内存不够就升级为间隙锁甚至表锁；redo log写入量暴增，可能触发checkpoint阻塞；主从延迟瞬间拉大。

真正难处理的是：这种慢不是“单条慢”，而是“一跑就卡死”，且SHOW PROCESSLIST里只看到Updating状态，看不出具体卡在哪。

安全做法：

• 用WHERE id BETWEEN ? AND ?按主键分段，每批≤5000行
• 每次UPDATE后加SLEEP(0.1)（应用层控制），避免冲击缓冲池
• 避开业务高峰执行，尤其要确认binlog_format不是STATEMENT——否则大事务在从库重放时极易OOM

索引列UPDATE的性能代价常被低估：它不只是“改数据”，还捆绑着索引校验、锁管理、日志写入、缓冲池淘汰四重开销。最容易忽略的是——你看到的“执行了1秒”，背后可能是300ms在等锁、400ms在刷索引页、200ms在写redo，剩下100ms才是真正在改那行数据。