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万行，在未加<code>LIMIT且无分批次控制时，InnoDB会尝试一次性持有80万个行锁。内存不够就升级为间隙锁甚至表锁；redo log写入量暴增，可能触发checkpoint阻塞；主从延迟瞬间拉大。
真正难处理的是：这种慢不是“单条慢”，而是“一跑就卡死”，且SHOW PROCESSLIST里只看到Updating状态，看不出具体卡在哪。
安全做法：
- 用
WHERE id BETWEEN ? AND ?按主键分段，每批≤5000行 - 每次UPDATE后加
SLEEP(0.1)（应用层控制），避免冲击缓冲池 - 避开业务高峰执行，尤其要确认binlog_format不是
STATEMENT——否则大事务在从库重放时极易OOM
