⑥ Extra 字段详解与 SQL 调优方法论

对应第 106 ~ 108 讲(+ 第 85 讲总纲)· Using index / where / filesort / temporary 与调优闭环

好消息 · Using index / Using index condition(第 106 讲) 坏消息 · Using where / join buffer(第 107 讲) Using filesort —— 排序用不上索引(第 108 讲) Using temporary —— 临时表分组/去重(第 108 讲) SQL 调优方法论闭环(第 85 讲总纲 + 第 108 讲总结) 好信号 坏信号 排序环节 分组环节 复查不达标 → 回到第②步继续找瓶颈 · 循环直到每一步都基于索引执行 其他字段告诉你 怎么查表 · 用哪个索引 · 预估多少行 Extra 告诉你隐藏动作 要不要回表?排序?临时表?JOIN 缓存? 许多性能问题的唯一线索 Extra 绝不是无关紧要的字段 Using index · 覆盖索引(免回表) 查询只用二级索引就能拿到全部所需字段 例:select x1 from t1 where x1='xxx' → 索引里就有答案 Using index condition · 索引条件下推 先按索引查出数据,再用其余条件比对筛选 例:x1 > 'xxx' AND x1 LIKE '%xxx' → 先范围查再逐条比对 调优方向:让查询列尽量被索引覆盖 → 看到 Using index 就是好信号 Using where · 逐行过滤 全表扫描后逐行过滤 · 或索引查完再用索引外字段过滤 Using join buffer (Block Nested Loop) 连接列没索引 → 内存分块缓存减少全表扫描次数(补救措施) 根除方法 给被驱动表的连接列建索引(详见专题②) 坏写法 · ORDER BY 无索引列 order by x2(x2 无索引)→ 全表数据写入临时磁盘文件再排序 type=ALL + Extra=Using filesort · 性能极差 好写法 · ORDER BY 索引列 order by x1 limit 10 → 按索引顺序直接取 10 条 type=index + key=index_x1 · 没有 filesort group by / union / distinct 用不上索引 全表数据放进临时表完成分组 / 去重 / 聚合 大量磁盘操作 · 性能极低 例:select x2, count(*) from t1 group by x2 x2 无索引 → 5788 行全部进临时表分组聚合 调优方向:给分组列建索引 · union 去重同样走临时表 ① 看懂执行计划 每个步骤到底怎么执行 ② 定位性能瓶颈 全表扫描 · 扫描量过大 · filesort ③ 动手优化 改写 SQL · 改良索引设计 ④ 复查执行计划 验证每一步都基于索引执行 核心思想:执行计划里哪里出现全表扫描 / 扫描量过大,就优化哪里 —— 让每个执行步骤都走索引 图例 好信号 / 好写法 坏信号 / 坏写法 实例分析 方法论步骤 调优闭环回流

Extra 速查:绿灯 vs 红灯

  • • Using index:覆盖索引免回表 —— 绿灯
  • • Using index condition:索引条件下推 —— 可接受
  • • Using where:逐行过滤 —— 结合 rows/filtered 评估
  • • Using join buffer:连接列缺索引 —— 红灯,去建索引
  • • Using filesort / temporary:磁盘排序 / 临时表 —— 红灯

排序与分组的最优解

  • • order by 索引列:直接按索引顺序读取,无排序动作
  • • order by 无索引列:数据落临时磁盘文件再排序,极慢
  • • group by / distinct / union:能用索引就用索引
  • • 用不上索引 → 全部进临时表,大量磁盘操作
  • • 调优口诀:让排序、分组、去重的列都有索引可依

整门课的最后一句话总结

  • • SQL 调优 = 看懂执行计划 + 针对性改造
  • • 索引设计只是 SQL 优化的入门技巧之一
  • • 复杂 SQL 调优必须理解底层:数据页 / 索引树 / 回表
  • • 目标状态:执行计划每一步都基于索引执行
  • • 日常实践:SQL 尽量简单 + 建好必要索引,性能通常就不是问题