频繁更新字段加索引会显著拖慢写入速度，因每次UPDATE需同步维护数据和索引、触发页分裂并写日志；读写比超10:1且无更好过滤条件时才考虑加索引。
频繁更新的字段加索引会拖慢写入速度
MySQL 对 UPDATE 操作需要同时维护数据行和所有相关索引。只要字段在某个索引中（无论是单列还是联合索引的一部分），每次更新该字段，InnoDB 就得定位 B+ 树节点、修改叶节点记录、可能触发页分裂，还要写 redo log 和 undo log。实测表明：对高并发更新场景，给高频变更字段加索引，QPS 可能下降 30%～60%，延迟毛刺明显增多。
常见错误现象：SHOW PROCESSLIST 中大量 Updating 状态卡住；innodb_row_lock_waits 持续上涨；慢查询日志里出现本不该慢的 UPDATE ... SET status=... WHERE id=...。
- 判断是否“频繁”：单表每秒
UPDATE超过 50 次，且目标字段参与 WHERE 或 SET，就要警惕索引开销 - 联合索引中包含更新字段更危险——哪怕只改其中一列，整个索引项都要重写
- 如果该字段还被用作
ORDER BY或GROUP BY，优先考虑覆盖查询需求的其他稳定字段建索引，而非直接给它建
什么时候必须给更新字段加索引？
不是“能不能”，而是“不加就跑不动”。典型场景是：该字段虽常更新，但更是高频查询条件，且没有其他过滤性更强的字段可用。例如订单表的 status 字段，每笔支付成功都要 UPDATE status='paid'，但运营后台又频繁执行 SELECT * FROM orders WHERE status='shipped' AND created_at > '2024-01-01'。
此时不加索引，全表扫描压力远大于索引维护成本。关键看读写比：如果 SELECT 次数是 UPDATE 的 10 倍以上，且无法通过时间范围、分库分表等手段规避扫描，索引就是必要代价。
- 务必用
EXPLAIN验证：不加索引时是否走了type=all，加了之后是否变成ref或range - 避免冗余：如果已有联合索引
(status, created_at)，就别再单独建INDEX(status) - 考虑前缀索引：对长文本字段（如
varchar(500)）更新频繁又需查前缀，用INDEX(content(10))减少索引体积
替代方案比硬加索引更有效
与其在热字段上硬扛索引开销，不如把查询压力从原表移走。最常用且低风险的是冗余字段 + 应用层双写，或用物化视图思路做轻量聚合表。
比如用户积分变动频繁，但“当前总积分”又常被查，不要直接在 user_points_log 表的 change_amount 上建索引，而是在 users 表里加 total_points 字段，每次写日志时同步更新它，并给 total_points 建索引——这个字段本身几乎不更新，索引极稳定。
- 用
INSERT ... ON DUPLICATE KEY UPDATE替代先SELECT再UPDATE，减少一次索引查找 - 批量更新时合并语句：把 100 次单行
UPDATE改成一条INSERT INTO ... VALUES (...), (...) ON DUPLICATE KEY UPDATE - 异步补偿：对非强实时场景（如统计类字段），用消息队列延迟更新汇总表，主表只负责写原始事实
建索引前必须检查的三个配置
即使决定加索引，InnoDB 的底层行为也会极大影响实际效果。默认配置往往不适合高写入负载。
容易被忽略的关键点：innodb_flush_log_at_trx_commit=1 是安全底线，但若业务允许短暂异常丢失，可设为 2；innodb_buffer_pool_size 不足会导致索引页频繁换入换出；而 innodb_log_file_size 太小会引发频繁 checkpoint，加剧写放大。
- 确认
innodb_change_buffering是否开启（默认all）：它能缓存非唯一索引的更新操作，显著降低随机 I/O——但仅对非唯一二级索引生效 - 检查
information_schema.INNODB_METRICS中dml_ibuf_discard和dml_ibuf_merges指标，判断 change buffer 是否真正在起作用 - 如果表有全文索引（
FULLTEXT），更新含中文字段时注意ngram_token_size设置，否则索引构建会成为隐形瓶颈
事情说清了就结束。真正难的不是“加不加索引”，而是搞明白那条 UPDATE 背后到底有多少 SELECT 在等它，以及这些 SELECT 能不能换个姿势查。
