高并发下索引失效主因是查询未走索引、写多导致B+树维护开销大、覆盖索引滥用；应通过EXPLAIN验证执行计划、删冗余索引、合理设计复合索引与覆盖索引，并善用change buffer。
高并发下索引没用？先看查询是否真走索引
很多团队反馈“加了索引，QPS 上去后响应反而更慢”，往往根本原因不是索引无效，而是查询压根没走索引。MySQL 在高并发时会因统计信息过期、隐式类型转换、OR 条件滥用或 LIKE 前缀通配（如 LIKE '%abc'）导致执行计划退化为全表扫描。
实操建议：
- 高并发前务必用
EXPLAIN FORMAT=TRADITIONAL检查核心 SQL 的type字段——ALL或index是危险信号； - 在从库或低峰期执行
ANALYZE TABLE更新统计信息，避免优化器误判； - 避免在索引列上做函数操作，比如把
WHERE DATE(create_time) = '2024-01-01'改成WHERE create_time >= '2024-01-01' AND create_time ； - 用
SHOW PROFILES和SHOW PROFILE FOR QUERY N定位慢在解析、锁等待还是磁盘 I/O，别一上来就调索引。
复合索引顺序错一位，高并发时性能可能断崖下跌
复合索引的字段顺序不是按“出现频率”排，而是严格遵循「最左前缀匹配」和「过滤性优先」原则。高并发下，一个排序错误的复合索引会导致大量线程争抢相同索引页，加剧 latch 等待甚至死锁。
实操建议：
- 把区分度最高的字段放最左，例如用户表中
status（只有 0/1）绝不能放user_id（唯一）前面； - 如果查询常带
WHERE a = ? AND b > ? ORDER BY c，索引应建为(a, b, c)，而非(a, c, b)——否则ORDER BY无法复用索引排序； - 用
SELECT COUNT(DISTINCT column)估算区分度，比凭经验判断更可靠； - 线上建复合索引前，先用
pt-duplicate-key-checker扫描冗余索引，避免新增索引加重写放大。
高并发写多读少场景，B+树索引可能成瓶颈
当单表每秒写入超 500 行且含多个二级索引时，每个 INSERT/UPDATE 都要维护所有索引 B+ 树的页分裂、合并与缓冲池刷脏，极易引发 innodb_row_lock_waits 上升和 Buffer Pool 命中率骤降。
实操建议：
- 删掉长期不用或过滤效果差的二级索引（如仅用于
SELECT COUNT(*) WHERE deleted = 1的单列索引）； - 对高频写入字段（如计数器、状态更新），考虑用缓存层（Redis）暂存再批量落库，减少索引更新频次；
- 启用
innodb_change_buffering = all（默认已开），让非唯一二级索引的变更先缓存在内存中，降低随机 I/O； - 监控
Innodb_ibuf_merge_inserts和Innodb_ibuf_merges，若比值长期低于 5，说明 change buffer 效果不佳，需重新评估索引必要性。
覆盖索引在高并发查询中能省掉回表，但别盲目追求
覆盖索引（Using index）确实能避免聚簇索引回表，对 SELECT id, name FROM user WHERE status = 1 这类查询提升显著。但若为了“覆盖”而把所有常用字段塞进索引，会导致索引体积暴涨、写放大加剧，在 SSD 寿命和 Buffer Pool 利用率上付出代价。
实操建议：
- 只对高频、延迟敏感、且返回字段固定的查询设计覆盖索引，例如订单列表页的
SELECT order_id, amount, status FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 20； - 用
INFORMATION_SCHEMA.STATISTICS查看索引平均长度，单条索引记录超过 2KB 就该警惕； - 避免在覆盖索引中包含
TEXT、BLOB或长VARCHAR字段——MySQL 不会真正把它们存进索引页，但会误导优化器选择； - 注意
SELECT *永远无法触发覆盖索引，高并发接口必须显式列出字段。
真正卡住高并发 MySQL 的，往往不是“有没有索引”，而是“索引是否被正确命中”“写入路径是否被索引拖累”以及“覆盖索引是否掩盖了更深层的设计问题”。这些地方改对一处，比加十个索引都管用。
