真正拖慢高频UPDATE的索引是WHERE未使用但字段频繁更新的二级索引，如status、updated_at等；应优先删除或重构这类索引，因其强制同步维护导致页分裂、I/O压力和锁争抢。
高频UPDATE时，哪些索引最该删
真正拖慢写入的，不是你查得最多的索引，而是那些WHERE里没用上、但字段又总在变的二级索引。比如 status、updated_at、version 这类字段，只要出现在 UPDATE 的 SET 子句里，对应索引就会被强制更新——哪怕你只改了一行、只改了一个字段。
- 用
SHOW INDEX FROM t列出所有索引，重点标出非主键、非唯一、且字段更新频率 ≥ 1次/秒的索引 - 临时禁用测试：执行
ALTER TABLE t ALTER INDEX idx_status INVISIBLE（注意：这不减少写开销，仅用于对比查询计划） - 真删索引前先备份：比如
ALTER TABLE t DROP INDEX idx_updated_at，再压测UPDATE延迟是否下降 30% 以上 - 如果删除后写入速度明显回升，说明该索引就是瓶颈；别犹豫，直接移除或重构
复合索引设计必须避开的三个坑
建复合索引不是把常用字段堆一起就行，顺序和字段数直接影响写放大程度。B+树页分裂在高频更新下会变成随机I/O洪峰。
- 字段数别超 3 个：
(user_id, status, updated_at)看似覆盖全，但每次updated_at变，整条索引记录都要重写，等价于每行更新都触发页分裂 - 高选择性字段必须放最左：比如
user_id（千万级唯一值）比status（只有 3–5 个枚举值）更适合放第一位，否则WHERE status = 'pending'还是走全索引扫描 - 避免把
TIMESTAMP或DATETIME放进索引前缀：它们几乎每次UPDATE都变，索引更新开销接近全表扫描级别
覆盖索引不是万能解药，得看读写比
覆盖索引能省回表，但代价是索引体积更大、写入更重。对日均百万级 UPDATE 的表，它可能让写性能雪上加霜。
- 只对 读远多于写 的字段组合建覆盖索引，例如
(order_id, user_id, amount)用于报表查询，但绝不用于UPDATE t SET amount = amount + 1 WHERE order_id = ? - 检查
performance_schema.table_io_waits_summary_by_index_usage，确认该索引的COUNT_READ是COUNT_WRITE的 10 倍以上才值得保留 - 对高频更新字段，宁可用生成列降频：比如把
updated_at拆成updated_day（DATE(updated_at)），再建INDEX idx_updated_day ON t (updated_day)
不可见索引不能替代索引精简
INVISIBLE 索引只是让优化器“看不见”，但 InnoDB 依然会在每次 INSERT/UPDATE/DELETE 时同步维护它——写放大、redo log 增长、页分裂，一个都不少。
- 误用场景：以为设成
INVISIBLE就能“异步更新”，结果UPDATE延迟照旧，还多了索引元数据管理开销 - 合理用途：灰度下线前观察查询计划变化，或临时屏蔽某个索引做 A/B 对比
- 真正减负，只能靠删：用
pt-duplicate-key-checker扫描重复索引，合并(a)和(a,b)为单个(a,b)，再删掉孤立的(a)
