高并发下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 使用，而不是“以防万一”。可借助：
