高并发下索引没用？先看查询是否真走索引
很多团队反馈“加了索引，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 的，往往不是“有没有索引”，而是“索引是否被正确命中”“写入路径是否被索引拖累”以及“覆盖索引是否掩盖了更深层的设计问题”。这些地方改对一处，比加十个索引都管用。
