EXPLAIN 是慢查询优化的第一步，因其能暴露真实执行路径，需重点关注type、key、rows和Extra字段，避免误判索引生效情况。
为什么 EXPLAIN 是慢查询优化的第一步
不看执行计划就调索引，基本等于蒙眼调参。MySQL 优化的核心是让查询走对索引、少扫描行数。EXPLAIN 能暴露真实执行路径，重点关注 type（是否用到索引）、key（实际使用的索引）、rows（预估扫描行数）、Extra（是否有 Using filesort 或 Using temporary）。
常见误判：看到 key 非 NULL 就以为优化成功 —— 实际可能是走了低效的联合索引前缀，或 rows 高达几十万。
-
type = ALL或index：全表/全索引扫描，必须优化 -
Extra含Using filesort：ORDER BY无法利用索引排序，考虑覆盖索引或调整排序字段顺序 -
rows远大于结果集数量：说明索引区分度差或条件未命中索引最左前缀
联合索引怎么建才不白建
联合索引不是字段堆砌，而是按「过滤强度高 + 排序需求 + 覆盖查询」三者权衡。错误做法是把所有 WHERE 字段全塞进一个索引，结果发现 WHERE a = ? AND c = ? 根本用不上 (a, b, c) 索引 —— 因为跳过了中间字段 b。
正确顺序原则：等值查询字段放前面，范围查询字段放最后，排序字段尽量紧接等值字段之后。
- 查询
WHERE status = ? AND create_time > ? ORDER BY update_time→ 索引应为(status, create_time, update_time)，而非(status, update_time, create_time) - 如果还要
SELECT id, name, status，可扩展为覆盖索引(status, create_time, update_time, id, name)，避免回表 - 字段选择性低（如
gender只有男/女）不要放在联合索引最左位，除非它是高频等值过滤且后续字段高度依赖它
ORDER BY 和 LIMIT 配合时的隐藏陷阱
分页深翻（如 LIMIT 10000, 20）性能骤降，本质是 MySQL 仍需扫描前 10020 行再丢弃。即使有索引，ORDER BY 字段没参与过滤时，排序成本也随偏移量线性增长。
- 用游标分页替代
OFFSET：上一页最后一条记录的id或create_time作为下一页查询条件，例如WHERE id > 12345 ORDER BY id LIMIT 20 - 确保
ORDER BY字段在索引中连续且无范围条件打断，否则会退化为文件排序 - 避免
SELECT *配合大LIMIT：回表开销放大，优先用覆盖索引只查必要字段
哪些“优化”反而让查询更慢
有些操作看似合理，实则触发 MySQL 的隐式转换或索引失效，比如字符串字段用数字查询、函数包裹索引字段、或对索引列做运算。
-
WHERE mobile = 13812345678：若mobile是VARCHAR，会触发全表扫描（类型转换导致索引失效）→ 改为'138123
45678'
-
WHERE YEAR(create_time) = 2025：函数作用于索引列 → 改为create_time BETWEEN '2025-01-01' AND '2025-12-31' -
WHERE status IN ('A','B') AND amount + 100 > 500：对索引列amount做运算 → 改为amount > 400 - 过度使用
FORCE INDEX：掩盖了真正的问题（如统计信息过期），应先ANALYZE TABLE更新统计信息
慢查询优化不是堆技巧，而是从执行计划出发，逐层验证索引有效性、数据分布和查询写法之间的匹配关系。最容易被忽略的是：没确认查询是否真的走到了你认为的那个索引 —— EXPLAIN 后加 FORMAT=JSON 查看 used_columns 和 key_parts 才算闭环。
