update修改索引列会触发b+树同步更新，导致随机i/o、页分裂等性能问题；应避免无意义更新，优先更新非索引列，慎用冗余或过长前缀索引。
频繁 UPDATE 导致索引性能骤降的典型表现
MySQL 在执行 UPDATE 时，只要修改了索引列（包括主键、唯一键、普通二级索引字段），就必须同步更新对应 B+ 树索引页——这会引发随机 I/O、页分裂、缓冲池污染，甚至锁升级。常见现象包括：innodb_row_lock_time_avg 突增、Handler_read_rnd_next 暴涨、慢查日志里大量 UPDATE ... WHERE id = ? 耗时超 100ms。
UPDATE 前先判断值是否真有变化
避免“无意义更新”是最直接有效的手段。MySQL 不会自动跳过未变更的索引维护，哪怕 SET status = status 这种写法也会触发索引重写。必须由应用层或 SQL 层显式过滤：
- 应用层：读取原记录，比对要更新的字段值，仅当不同时才发起
UPDATE - SQL 层（适合简单场景）：
UPDATE users SET last_login = NOW() WHERE id = 123 AND last_login != NOW();
注意：这里用NOW()是示例，实际应传入具体时间戳变量；对字符串/数字类型，可直接用参数比对，如status != ? - 慎用
WHERE col IS NOT NULL类条件——它无法阻止索引更新，只是减少行扫描
批量更新时合并操作并避开二级索引列
单条 UPDATE 更新 1 行，和 100 条合并为 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE INTO，索引维护开销差异巨大。关键点在于：
- 优先更新非索引列（如
content、memo），这类更新只改聚簇索引叶子节点，不触碰二级索引 - 若必须更新索引列，尽量用主键做条件，避免
WHERE匹配二级索引（否则先查二级索引再回表，再更新二级索引，三重开销） - 大批量更新前临时禁用非必要索引（
ALTER TABLE t DROP INDEX idx_xxx），更新完再重建——适用于离线任务，线上慎用
索引设计本身加剧 UPDATE 开销的隐蔽坑
不是所有索引都“平等”。以下设计会让 UPDATE 更痛苦：
-
UNIQUE约束索引：每次更新都要做唯一性校验（全索引扫描或范围查找），比普通INDEX多一次逻辑检查 - 冗余联合索引：比如已有
(a, b)，又建了(a, b, c)，更新c时两个索引都要维护 - 过长的字符串索引：如
INDEX(title(255))，即使只改title后半段，整个前缀索引项仍需重写 - 频繁被
UPDATE的列，不该出现在多个二级索引中——宁可加宽单个索引，也不要分散建多个
真正难处理的是业务强依赖实时更新 + 多索引覆盖的场景，这时得接受部分延迟，用异步队列或物化视图解耦，而不是硬扛索引维护成本。
