加了索引仍慢的真正瓶颈是扫描行数过多或回表过重；需通过EXPLAIN检查rows值和Extra字段，结合选择性分析、复合索引顺序优化、覆盖索引设计及游标分页等手段精准治理。
加了索引还慢，不是索引没生效，而是“扫描行数太多”或“回表太重”——这两点才是真实瓶颈。
EXPLAIN 显示 key 有值但 rows 过大
这说明索引确实被用了，但匹配的行数远超预期。比如 rows=500000，哪怕走索引，也要读取 50 万行数据页，I/O 开销巨大。
- 先查字段选择性：
SELECT COUNT(DISTINCT column_name) / COUNT(*) FROM table_name;，低于 0.1 就别单独建索引 - 复合索引顺序错会导致范围扫描扩大，例如索引
(a, b, c)，而查询是WHERE a = 1 AND c = 3，b被跳过，c实际无法用上 - 如果
WHERE条件里有OR且部分字段无索引，优化器可能直接放弃整个索引，改走全表扫描
type 是 ref 或 range，但 Extra 出现 Using filesort 或 Using temporary
这意味着虽然过滤阶段走了索引，但排序或分组仍需额外操作，尤其是 ORDER BY 字段不在索引覆盖范围内时。
- 把
ORDER BY字段塞进复合索引尾部，例如常查WHERE status = 1 ORDER BY created_at DESC，就建INDEX(status, created_at) -
SELECT *容易触发回表；改成只查索引已包含的字段（如SELECT id, name配合INDEX(name, id)），就能走覆盖索引，避免回表 -
GROUP BY和ORDER BY字段顺序不一致也会导致无法复用索引，尽量保持物理顺序一致
大偏移量分页：LIMIT 1000000, 20
MySQL 必须先定位到第 1000000 行，再取 20 行——前面 100 万行全要扫描，索引也救不了。
- 改用游标分页：记录上一页最后的
id值，下一页查WHERE id > last_id ORDER BY id LIMIT 20 - 若必须用偏移量，先用覆盖索引子查询缩小主表扫描范围：
SELECT * FROM t JOIN (SELECT id FROM t WHERE ... ORDER BY id LIMIT 1000000, 20) AS tmp USING (id) - 超过 10 万行偏移量后，性能衰减明显，前端应限制最大翻页深度或改用搜索+筛选替代传统分页
真正卡住查询的，往往不是“有没有索引”，而是“索引能不能减少物理读”和“要不要回表”。每建一个索引前，先跑一遍 EXPLAIN 看 rows 和 Extra，比盲目加索引管用得多。
