Navicat不直接解析子查询嵌套结构，执行计划需人工依据id和select_type判断：id越大越先执行，DERIVED表示FROM子查询，SUBQUERY为SELECT/ WHERE中非关联子查询；遇空表或报错时应改用EXPLAIN FORMAT=TREE或重写为JOIN/EXISTS验证。
Navicat 里点不出子查询的执行计划
Navicat 本身不生成或展示执行计划，它只是把 EXPLAIN 命令的结果以表格形式呈现。真正干活的是底层数据库（MySQL/PostgreSQL），而 Navicat 只负责发送语句、接收并渲染结果。如果你在 Navicat 中对含子查询的 SQL 点“解释”却看到空表、报错或字段缺失，大概率是子查询结构导致数据库无法直接 EXPLAIN ——比如子查询在 SELECT 列表里（标量子查询）、或嵌套在 WHERE 中用了 IN (SELECT ...) 且未加限制。
实操建议：
- 先手动在 Navicat 查询窗口中执行
EXPLAIN FORMAT=TRADITIONAL SELECT ...（MySQL 8.0+ 推荐用FORMAT=TREE）； - 若报错
ERROR 1221 (HY000): Incorrect usage of UNION and ORDER BY或类似提示，说明子查询带了ORDER BY/LIMIT却没包在派生表里 —— 这类写法 MySQL 不允许直接EXPLAIN； - 对
WHERE x IN (SELECT y FROM t2)类型，可临时改写为WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.y = t1.x)再EXPLAIN，更容易看出是否走索引； - PostgreSQL 用户注意：Navicat 对
EXPLAIN (ANALYZE, BUFFERS)的解析较弱，建议复制完整输出到文本编辑器里看缩进和节点耗时。
哪些子查询能安全改写成 JOIN
不是所有子查询都适合或值得改写。关键看语义是否等价、数据量是否可控、以及改写后是否真能提升性能。常见可改写场景有三类：
-
SELECT a.*, (SELECT b.name FROM b WHERE b.id = a.b_id)→ 改为LEFT JOIN b ON a.b_id = b.id，前提是b.id是主键或唯一键，否则会放大行数； -
SELECT * FROM a WHERE a.id IN (SELECT b.a_id FROM b WHERE b.status = 'active')→ 改为INNER JOIN b ON a.id = b.a_id AND b.status = 'active'，但要注意去重：若b中一个a_id对应多条记录，JOIN后a行会被重复，需加DISTINCT或用GROUP BY； -
SELECT * FROM a WHERE EXISTS (SELECT 1 FROM b WHERE b.a_id = a.id AND b.created_at > '2024-01-01')→ 改为INNER JOIN b ON a.id = b.a_id AND b.created_at > '2024-01-01'，此时无需担心重复，但必须确认业务允许丢失无匹配b记录的a行（即EXISTS语义是“至少一条”，JOIN是“至少一条且返回所有匹配”）。
改写后执行计划变差？检查这几个地方
有时明明把 IN 子查询换成 JOIN，EXPLAIN 却显示 type: ALL（全表扫描）、rows 暴增、甚至出现 Using temporary; Using filesort。这不是 JOIN 本身的问题，而是改写引入了隐式笛卡尔积或索引失效：
- 漏写了
ON条件中的关键过滤项，比如把JOIN b ON a.id = b.a_id WHERE b.status = 'active'写成JOIN b ON a.id = b.a_id然后在WHERE里筛状态 —— MySQL 可能先做连接再过滤，而非先过滤b表； -
b.a_id列上没索引，而a.id是主键 —— 连接驱动顺序可能被优化器选反，导致对大表b全扫；可用STRAIGHT_JOIN（MySQL）强制驱动表顺序，或加/*+ Leading(a) */（Oracle/PG via hint）； - 改写后语句返回字段增多（比如
SELECT *包含了b表所有列），触发了Using temporary，尤其当ORDER BY或GROUP BY涉及多表字段时； - 原
IN子查询结果集很小（如几十行），而JOIN后匹配出几万行 —— 此时子查询反而是更优策略，别硬改。
Navicat 中对比改写前后执行效率的实操技巧
光看 EXPLAIN 的 rows 和 type 不够，得测真实耗时。Navicat 底部状态栏会显示“查询花费 X.XX 秒”，但这包含网络和客户端开销。更准的做法是：
- 在查询开头加
SELECT BENCHMARK(1, 1);（MySQL）清空查询缓存（如果启用），避免上次结果干扰； - 对同一语句连续执行 3 次，取中间值 —— 首次可能有磁盘读，末次可能被缓存，中间最稳；
- 若涉及大量数据，关掉 Navicat 的“限制行数”选项（默认 1000），否则
EXPLAIN显示的rows和实际执行行为脱节； - 导出两版执行计划为文本（右键结果表 → “复制为纯文本”），用
diff工具逐行比对key、rows、Extra字段差异，重点关注是否从NULL变成有效索引名、rows是否降两个数量级。
子查询改写不是机械替换，核心在于理解优化器如何选择访问路径，以及你的数据分布是否匹配那个路径。很多“标准答案”在小表上成立，一到生产环境就翻车——因为统计信息不准、索引碎片、或者根本没考虑 JOIN 引入的中间结果集大小。动手前，先用 SHOW INDEX FROM table_name 和 SELECT COUNT(*) 看清楚基数。
