索引过多是高并发写入抖动最常见根源——每多一个索引，写操作就得维护一棵B+树，导致写放大、锁等待变长、CPU刷脏页压力飙升；Index_length接近Data_length、Innodb_rows_inserted与Innodb_pages_written比值跌至2～5、EXPLAIN显示大量二级索引更新、LOG段中log i/o频率远超事务提交频率，均表明索引拖累写入；应优先删除仅服务于低频查询的单列WHERE索引（如created_at）、冗余索引及未被查询使用的索引。
索引过多是高并发写入抖动最常见、最容易被低估的根源——每多一个索引，INSERT、UPDATE、DELETE 就得多维护一棵 B+ 树，写放大直接翻倍。这不是“慢一点”，而是锁等待变长、CPU 刷脏页压力飙升、Innodb_buffer_pool_write_requests 和 Innodb_data_writes 比值严重失衡的信号。
怎么确认是索引拖慢了写入
别猜，用数据验证：
- 查
SHOW TABLE STATUS LIKE 'your_table'，重点关注Index_length：如果它接近甚至超过Data_length，说明索引开销已和数据本身持平，非常危险 - 对比指标：
Innodb_rows_inserted和Innodb_pages_written的比值。正常应在 10～50 之间；若跌到 2～5，大概率是索引在疯狂刷盘 - 执行
EXPLAIN FORMAT=JSON看写操作是否触发了大量二级索引更新（used_columns里出现非主键字段） - 观察
SHOW ENGINE INNODB STATUS\G中的LOG段：如果log i/o's done频率远高于事务提交频率，说明 redo 日志在为索引更新“擦屁股”
删哪些索引最安全、见效最快
优先砍掉对写入无贡献、只服务于低频查询的索引：
- 单列
WHERE索引，但该列SELECT查询占比 performance_schema.events_statements_summary_by_digest 查） - 前缀过长的
VARCHAR索引，比如INDEX (content(255))—— 实际查询几乎不用到那么长 - 重复索引：如已有
(user_id, status)，又单独建了(user_id)，后者可删 - 未被
EXPLAIN任何查询命中的索引（用sys.schema_unused_indexes视图，MySQL 8.0+） - 写入频繁但查询从不带
ORDER BY或GROUP BY的字段索引（例如updated_at单独建索引）
改写索引结构降低写入成本
保留必要索引，但让它们更“轻”：
- 把宽索引改成覆盖索引的最小集：比如原
INDEX (a,b,c,d,e)只用于WHERE a=? AND b=? ORDER BY c，可精简为INDEX (a,b,c) - 用
TINYINT或ENUM替代VARCHAR做状态字段索引（如status ENUM('pending','done','failed')），索引体积小、比较快 - 避免在索引列上做函数转换：
WHERE YEAR(created_at) = 2024会让整个索引失效，改用WHERE created_at >= '2024-01-01' AND created_at - 对高频写入表，考虑把部分查询索引移到
GENERATED COLUMN + STORED上，再建索引——减少主表 DML 对索引的直接冲击
为什么删完索引后还是抖？盯住这几个隐藏点
索引删了，但抖动没消失，往往卡在这些细节：
-
innodb_flush_neighbors = 1在 SSD 上没关：即使索引少了，这个参数仍会强制批量刷邻页，造成 I/O 放大。务必运行SELECT @@innodb_flush_neighbors确认是0 - 主键不是自增整数：用了
UUID或CHAR(36)，导致页分裂持续发生，新插入总要调整 B+ 树结构 —— 这种抖动和索引数量无关，但表现相似 - 表上有
FULLTEXT索引：它不走普通 B+ 树，而是独立的倒排索引，每次写入都要同步更新，且无法用常规方式禁用 -
innodb_log_file_size太小（如默认 48MB）：索引删了，但日志切换太频繁，照样触发 checkpoint 抖动。建议设为 1G～2G
