高并发下 SELECT 慢通常源于单条查询未走索引，需用 EXPLAIN 确认 type 为 ALL/index、key 为 NULL 或 rows 过大；常见原因包括函数操作、隐式转换、违反最左前缀、OR 混用无索引字段、ORDER BY+LIMIT 深分页等，推荐游标分页替代 OFFSET。
高并发下 SELECT 慢，先看是否走了索引
很多“高并发慢”问题其实和并发关系不大，本质是单条查询没走索引，被放大成雪崩。用 EXPLAIN 看执行计划是最直接的判断方式：type 是 ALL 或 index、key 为 NULL、rows 远大于实际返回行数，基本可以断定索引失效。
常见诱因包括：
-
WHERE条件对字段用了函数或表达式，比如WHERE YEAR(create_time) = 2024 - 隐式类型转换 ，比如
user_id是VARCHAR，但查询写了WHERE user_id = 123（数字） - 联合索引最左前缀没满足，比如索引是
(a, b, c)，却只查WHERE b = ? AND c = ? - 使用了
OR且部分条件无法走索引，尤其混用无索引字段时
ORDER BY 和 LIMIT 组合导致索引失效
高并发分页场景（如 ORDER BY created_at DESC LIMIT 10 OFFSET 10000）容易触发全索引扫描甚至临时表，因为 MySQL 仍需跳过前 10000 行。即使 created_at 有索引，OFFSET 越大，性能越差。
更优做法是避免深分页：
- 用游标分页：记录上一页最后一条的
created_at和id，下一页查WHERE created_at - 对高频分页字段建覆盖索引，比如
(status, created_at, id)，让排序 + 查询都在索引中完成 - 不依赖
OFFSET的业务逻辑尽量改用基于主键 / 时间戳的范围查询
写操作多时，索引不是越多越好
每新增一个索引，INSERT/UPDATE/DELETE 都要同步更新所有索引 B+ 树，高并发写入下会明显拖慢响应，还可能加剧行锁 / 间隙锁冲突。
判断是否该保留某个索引，看它是否真正被 WHERE、JOIN、ORDER BY 或 GROUP BY 使用，而不是“以防万一”。可借助：
-
performance_schema.table_io_waits_summary_by_index_usage查索引实际命中次数（MySQL 8.0+） -
sys.schema_unused_indexes视图识别长期未被使用的索引 - 慢日志里反复出现的
WHERE条件组合，才是建联合索引的优先依据
例如，如果高频查询是 WHERE shop_id = ? AND status = ? ORDER BY updated_at DESC，那建 (shop_id, status, updated_at) 比单独给每个字段建单列索引有效得多。
高并发下唯一索引与插入冲突的隐性开销
带 UNIQUE 约束的索引在 INSERT …… ON DUPLICATE KEY UPDATE 或 REPLACE INTO 场景中，MySQL 需先做唯一性校验（可能触发间隙锁），再决定是插入还是更新。并发量大时，这个校验过程会成为瓶颈，甚至引发死锁。
缓解方式取决于业务容忍度：
- 能接受最终一致的，改用普通索引 + 应用层幂等控制
- 必须强唯一，但写入热点集中（如某
shop_id下高频插入），考虑拆分逻辑，比如加随机后缀再哈希分片 - 避免在高频写入字段上建唯一索引，除非业务强依赖；
PRIMARY KEY本身已是唯一索引，无需额外建
真正棘手的不是索引建不建，而是哪些查询路径必须走索引、哪些写入路径会被索引反向拖累——这两边得一起看，不能只盯着 SELECT 优化。
