频繁更新字段加普通索引会显著拖慢写入速度，因每次UPDATE需同步删除旧索引项、插入新索引项、可能触发页分裂，并写redo/undo log；联合索引中该字段越靠前代价越大，且易引发锁竞争与性能毛刺。
频繁更新的字段加普通索引，本质是在每次写操作上主动叠加一次甚至两次 B+ 树维护开销——不是“慢一点”，而是“锁住、分裂、日志全来一遍”。
UPDATE 时索引到底发生了什么？
只要字段出现在任何普通索引（单列或联合索引）中，InnoDB 就必须在每次 UPDATE 该字段时：定位旧索引项 → 删除它 → 插入新索引项 → 可能触发页分裂 → 写 redo log 和 undo log。这不是“顺带更新”，而是强制同步的两次 B+ 树操作。
- 联合索引中该字段越靠前（如
INDEX(status, user_id)），代价越大：前缀变化导致整条索引路径重定位，无法复用节点缓存 - 即使只改
status，但索引是(status, created_at)，整个索引项仍要重写，created_at值没变也没用 - 高并发下，多个线程争抢同一索引页的
index latch，SHOW PROCESSLIST里大量卡在Updating状态
哪些现象说明你被“更新索引”拖垮了？
别等服务报警才怀疑索引——这些信号更早、更准：
-
innodb_row_lock_waits持续上涨，且集中在某张表 - 慢查询日志里出现形如
UPDATE ... SET status = 'done' WHERE id = ?的语句，执行时间忽高忽低（毛刺） - 主从延迟突增，而写入 QPS 并未明显上升（说明写入内部开销畸高）
-
SELECT * FROM information_schema.STATISTICS WHERE table_name = 't_order' AND column_name = 'status'查出多个含status的索引，其中至少一个是冗余的
什么时候“不得不加”？判断依据只有两个硬指标
不是看业务重要性，而是看数据行为是否满足以下条件：
- 该字段确实是高频查询的过滤条件（
WHERE status = 'shipped'占所有 SELECT 的 10% 以上） - 不加索引时，
EXPLAIN显示type = all，且无法通过时间范围、分库分表、冗余字段等方式规避全表扫描 - 读写比 ≥ 10:1（例如每秒 50 次
UPDATE status，但对应 500+ 次SELECT ... WHERE status = ?） - 已有联合索引已覆盖该查询（如
INDEX(status, created_at)），就绝不再建INDEX(status)—— 白送写开销
比“加不加索引”更重要的事
真正压垮系统的，往往不是单个索引，而是把查询压力全堆在热字段上。更有效的解法是绕开它：
- 用应用层双写 + 冗余字段（如
status_summary）替代直接查原始status，把更新和查询解耦 - 对长文本字段，别用
INDEX(content(255))，改用生成列：content_hash CHAR(32) AS (MD5(content)) STORED，再建INDEX(content_hash) - 确认
innodb_change_buffering是开启状态（默认all），它能缓存非唯一二级索引的更新，但只对离散更新有效 - 新增索引务必显式指定
ALGORITHM = INPLACE，否则老版本 MySQL 默认COPY，锁表时间不可控
最常被忽略的一点：索引不是“有没有”，而是“谁在用、怎么用、谁在扛成本”。一个 status 字段出现在三个索引里，其中两个只服务 0.3% 的查询，却承担 100% 的更新开销——这种冗余，比不加索引更危险。
