navicat执行计划无树形结构，嵌套层级需依id和select_type人工判断：id越大通常越先执行，同id属同一阶段；derived表示from子查询，subquery为select/where中非关联子查询。
navicat 本身不解析嵌套层级，子查询的执行计划必须靠人工拆解 + 看 id 和 select_type 判断执行顺序和代价。
怎么看子查询在执行计划里的位置
Navicat 的「解释」结果是扁平表格，没有树形结构。真正反映嵌套关系的是两列：id 和 select_type：
-
id越大，通常越先执行（尤其当外层依赖内层结果时），比如DERIVED子查询的id往往比外层高 -
select_type = DERIVED表示该行对应一个FROM中的子查询，MySQL 会把它物化成临时表；select_type = SUBQUERY表示出现在SELECT或WHERE中的非关联子查询，可能只执行一次 - 若多个行
id相同，说明它们属于同一执行阶段（如 JOIN 多表）；若id为空（NULL），常见于 UNION RESULT 或优化器合并后的节点
为什么子查询里出现 type = ALL 特别危险
不是所有 ALL 都一样——在子查询中，它意味着“每次调用都要全表扫一遍”：
- 如果子查询是关联的（比如
WHERE x IN (SELECT y FROM t2 WHERE t2.a = t1.b)），而t2上没走索引，那么外层每返回一行，就触发一次t2全表扫描 - 查
rows列：若显示 1000，但t2实际只有 100 行，说明优化器误估；若显示 1000 且外层有 500 行，则等效于扫描 50 万行 -
key为NULL但possible_keys有值？重点检查字段顺序是否匹配、是否有隐式类型转换（如INT字段和字符串'123'比较）
哪些子查询会让 EXPLAIN 失效或失真
Navicat 调用的是数据库原生 EXPLAIN，而某些写法会让优化器无法生成可靠计划：
- 含用户变量的子查询（如
@rownum := @rownum + 1）：MySQL 不模拟变量状态，EXPLAIN结果无意义 -
UNION ALL包裹多个子查询：Navicat 通常只显示第一个分支的计划，其余被忽略 - CTE（
WITH子句）：MySQL 5.7 完全不支持EXPLAIN；8.0+ 支持但统一标为CTE，看不到各分支细节 - 5 层以上嵌套：部分 MySQL 版本直接报错
ERROR 1630，根本不出计划
真正有效的分析动作：分段 EXPLAIN
面对 SELECT * FROM (SELECT ... FROM (SELECT ...) t2) t1 这类结构，别指望 Navicat 自动展开。必须手动剥离：
- 把最内层子查询单独拎出来，加
EXPLAIN运行，看它的type、key、rows - 再把中间层当成独立查询运行，注意模拟外层传入的参数（比如把
WHERE t2.id = t1.id改成WHERE t2.id = 123测试） - 对每个子查询单独评估：是否能加索引？能否改写为
JOIN？是否可提前过滤（如加LIMIT）？
复杂点往往不在 Navicat 界面里，而在你是否意识到：同一个字段，在不同嵌套层级中，索引生效条件可能完全不同——比如外层用了 ORDER BY，内层却因函数包裹导致索引断裂，而 EXPLAIN 只字不提这点。
