频繁 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 层显式过滤： 应用层：读取原记录，比对要更新的字段值，仅当不同时才发起
UPDATESQL 层（适合简单场景）：
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的列，不该出现在多个二级索引中——宁可加宽单个索引，也不要分散建多个
真正难处理的是业务强依赖实时更新 + 多索引覆盖的场景，这时得接受部分延迟，用异步队列或物化视图解耦，而不是硬扛索引维护成本。
