如何写出高效率的SQL？看懂Explain执行就没问题了

explain select * from (select * from t3 where id=3952602) a ;

• derived：from 列表中出现的子查询，也叫做衍生表；mysql 或者递归执行这些子查询，把结果放在临时表里。

explain select * from (select * from t3 where id=3952602) a ;

• subquery：除了 from 子句中包含的子查询外，其他地方出现的子查询都可能是 subquery。

explain select * from t3 where id = (select id from t3 whereid=3952602 ) ;

• union：若第二个 select 出现在 union 之后，则被标记为 union；若 union 包含在 from 子句的子查询中，外层 select 将被标记为 derived。

explain select * from t3 where id=3952602 union all select * from t3;

• union result：从 union 表获取结果的 select ，因为它不需要参与查询，所以 id 字段为 null。

explain select * from t3 where id=3952602 union all select * from t3;

• dependent union：与 union 一样，出现在 union 或 union all 语句中，但是这个查询要受到外部查询的影响；
• dependent subquery：与 dependent union 类似，子查询中的第一个 SELECT，这个 subquery 的查询要受到外部表查询的影响。

table

• 表示 explain 的一行正在访问哪个表。
• 如果查询使用了别名，那么这里显示的是别名;
• 如果不涉及对数据表的操作，那么这显示为 null;
• 如果显示为尖括号括起来的就表示这个是临时表，后边的 N 就是执行计划中的 id，表示结果来自于这个查询产生;
• 如果是尖括号括起来的<union M,N>，与类似，也是一个临时表，表示这个结果来自于 union 查询的 id 为 M,N 的结果集。

type

• 访问类型，即 MySQL 决定如何查找表中的行。

• 依次从好到差：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL，除了 all 之外，其他的 type 都可以使用到索引，除了 index_merge 之外，其他的 type 只可以用到一个索引。一般来说，得保证查询至少达到 range 级别，最好能达到 ref。

1. system：表中只有一行数据（等于系统表），这是 const 类型的特例，平时不会出现，可以忽略不计。

2. const：使用唯一索引或者主键，表示通过索引一次就找到了，const 用于比较 primary key 或者 unique 索引。因为只需匹配一行数据，所有很快。如果将主键置于 where 列表中，mysql 就能将该查询转换为一个 const。

3. eq_ref：唯一性索引扫描，对于每个索引键，表中只有一行数据与之匹配。常见于主键或唯一索引扫描。

4. ref：非唯一性索引扫描，返回匹配某个单独值的所有行。本质也是一种索引。

5. fulltext：全文索引检索，全文索引的优先级很高，若全文索引和普通索引同时存在时，mysql 不管代价，优先选择使用全文索引。

6. ref_or_null：与 ref 方法类似，只是增加了 null 值的比较。

7. index_merge：表示查询使用了两个以上的索引，索引合并的优化方法，最后取交集或者并集，常见 and ，or 的条件使用了不同的索引。

8. unique_subquery：用于 where 中的 in 形式子查询，子查询返回不重复值唯一值；

9. index_subquery：用于 in 形式子查询使用到了辅助索引或者 in 常数列表，子查询可能返回重复值，可以使用索引将子查询去重。

10. range：索引范围扫描，常见于使用>,<,between ,in ,like等运算符的查询中。

11. index：索引全表扫描，把索引树从头到尾扫一遍；

12. all：遍历全表以找到匹配的行（Index 与 ALL 虽然都是读全表，但 index 是从索引中读取，而 ALL 是从硬盘读取）

13. NULL: MySQL 在优化过程中分解语句，执行时甚至不用访问表或索引。

possible_keys

• 显示查询可能使用到的索引。

key

• 显示查询实际使用哪个索引来优化对该表的访问；

• select_type 为 index_merge 时，这里可能出现两个以上的索引，其他的 select_type 这里只会出现一个。

key_len

• 用于处理查询的索引长度，表示索引中使用的字节数。通过这个值，可以得出一个多列索引里实际使用了哪一部分。
• 注：key_len 显示的值为索引字段的最大可能长度，并非实际使用长度，即 key_len 是根据表定义计算而得，不是通过表内检索出的。另外，key_len 只计算 where 条件用到的索引长度，而排序和分组就算用到了索引，也不会计算到 key_len 中。

ref

• 显示哪个字段或者常数与 key 一起被使用。

1. 如果是使用的常数等值查询，这里会显示 const。

2. 如果是连接查询，被驱动表的执行计划这里会显示驱动表的关联字段。

3. 如果是条件使用了表达式或者函数，或者条件列发生了内部隐式转换，这里可能显示为 func。

rows

• 表示 MySQL 根据表统计信息及索引选用情况，大致估算的找到所需的目标记录所需要读取的行数，不是精确值。

extra

• 不适合在其他列中显示但十分重要的额外信息。

• 这个列可以显示的信息非常多，有几十种，常用的有：
  

filtered

• 使用 explain extended 时会出现这个列，5.7 之后的版本默认就有这个字段，不需要使用 explain extended 了。
• 这个字段表示存储引擎返回的数据在 server 层过滤后，剩下多少满足查询的记录数量的比例，注意是百分比，不是具体记录数。

关于 MySQL 执行计划的局限性

1. EXPLAIN 不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况；
2. EXPLAIN 不考虑各种 Cache；
3. EXPLAIN 不能显示 MySQL 在执行查询时所作的优化工作；
4. 部分统计信息是估算的，并非精确值；
5. EXPALIN 只能解释 SELECT 操作，其他操作要重写为 SELECT 后查看。

查询计划案例分析

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

面试题总结

其它面试题（springboot、mybatis、并发、java中高级面试总结等）

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
转存中…(img-6rfZvKkc-1713633258822)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！