select_type是explain中标识select单元查询结构类型的明确分类，反映其在sql中的嵌套层级关系：simple为独立无嵌套查询，primary为最外层但含内部结构，derived对应from子句子查询，subquery为where/select中非相关子查询，dependent subquery需对外部行逐行执行，union/union result标识联合查询及结果集提取。
select_type 是什么：它直接告诉你这条执行计划属于哪一类查询结构
select_type 不是“查询有多复杂”的模糊描述，而是 mysql 执行器对当前 select 单元的明确分类。它出现在 explain 输出的第一列，每个 select（包括子查询、union 中的每个分支）都会对应一个 select_type 值。navicat 里点「解释」看到的表格，这一列就是关键线索——它不反映性能好坏，但能立刻帮你判断 sql 是否真如你写的那样“只是单表查”，还是悄悄触发了临时表、嵌套循环或去重逻辑。
SIMPLE 和 PRIMARY 的区别：不是“简单 vs 复杂”，而是“有没有被包裹”
很多用户看到自己的语句没写子查询，却在 select_type 看到 PRIMARY，就以为出错了。其实：SIMPLE 表示这个 SELECT 是独立存在的，没被任何 UNION、子查询或 FROM 子句中的嵌套包围；PRIMARY 则表示它是整个语句最外层的 SELECT，但内部一定有别的结构（比如子查询或 UNION）。换句话说：
- 写
SELECT * FROM user WHERE id = 1→select_type是SIMPLE - 写
SELECT * FROM (SELECT id FROM user LIMIT 10) t→ 外层SELECT是PRIMARY，括号内是DERIVED - 写
SELECT id FROM user WHERE id IN (SELECT user_id FROM order)→ 外层是PRIMARY，IN里的子查询是SUBQUERY
注意：SIMPLE 并不要求“不能有关联”，JOIN 多表查只要没子查询/UNION，仍是 SIMPLE。
UNION 相关 select_type 的真实含义：UNION ALL 和 UNION 的执行差异会直接体现在这里
当你用 UNION 拼接两个 SELECT，MySQL 必须去重，于是会建临时表存结果；而 UNION ALL 不去重，可跳过这步。这个区别在 select_type 上非常清晰：
- 第一个
SELECT：如果是UNION，它是DERIVED（因为要进临时表）；如果是UNION ALL，它也是DERIVED（仍需临时表承载合并结果） - 第二个及之后的
SELECT：无论UNION还是UNION ALL，select_type都是UNION - 最后还有一行：
select_type = UNION RESULT，表示从那个临时表取最终结果 —— 这一行只在UNION或UNION ALL中出现，且必然存在
所以如果你看到 UNION RESULT，就说明 Navicat 正在解析一个合并结果集，哪怕你只写了两个 SELECT，背后也已生成临时表。线上高并发场景下，应优先考虑能否改用 UNION ALL，并确认是否真需要合并——很多时候应用层拼接更可控。
容易忽略的陷阱：DEPENDENT SUBQUERY 和 MATERIALIZED 的实际影响
DEPENDENT SUBQUERY 看起来像普通子查询，但它意味着该子查询要为外部每一行重新执行一次（即“相关子查询”），性能极易崩盘。例如：SELECT name FROM user u WHERE EXISTS (SELECT 1 FROM order o WHERE o.user_id = u.id AND o.status = 'paid')，若 user 表有 10 万行，这个子查询可能执行 10 万次。
MATERIALIZED 则相反：MySQL 把子查询结果物化成临时表，只算一次，后续用索引查。它通常出现在 IN 子句中，比如 WHERE id IN (SELECT user_id FROM log WHERE time > '2026-04-01')。但要注意：如果物化表没走索引，或者数据量大导致临时表落磁盘，反而更慢。
这两个类型不会出现在简单语句里，但一旦出现，select_type 就是第一道预警信号——别急着调优 WHERE 条件，先看是不是子查询结构本身带来了不可控开销。
