Navicat的Explain面板会主动对同一条语句发起两次请求：一次查数据、一次取执行计划，尤其在旧版本中默认开启且不可关闭；子查询显示为DEPENDENT SUBQUERY是SQL语义所致，表示外层每行都触发一次执行，并非Navicat重复调用。
Navicat 的 Explain 面板触发两次执行
你看到的“子查询重复执行”，大概率不是 sql 本身被调用了两次，而是 navicat 在启用 explain plan 面板时，**主动对同一条语句发起了两次请求**：一次走数据路径（查结果），一次走优化器路径（取执行计划）。尤其当语句含子查询、union 或派生表（derived）时，mysql 服务端会真实执行两遍逻辑——第一次生成中间结果，第二次为生成执行计划再次解析并估算成本。
这种行为在 Navicat ≤16.0.x 版本中默认开启且不可关闭，只要顶部工具栏的 Explain 图标（齿轮+问号）处于高亮状态，哪怕你只点了一次“运行”，它也会悄悄补上第二轮 EXPLAIN FORMAT=TRADITIONAL 或 EXPLAIN ANALYZE（取决于数据库类型）。
- 右键结果窗口 → 确认没勾选
Auto-refresh result set，否则翻页/切 Tab 会再触发一轮 - 关掉顶部工具栏的
Explain和Profile按钮（图标常为图表或齿轮） - 不要在同一个查询标签页里反复点“运行”+“解释”，先清空结果再操作
- 若必须看执行计划，改用纯命令行方式：
EXPLAIN SELECT ...，避免 GUI 层干扰
子查询被标记为 DEPENDENT SUBQUERY 导致嵌套循环
执行计划里出现 DEPENDENT SUBQUERY，说明该子查询依赖外层查询的某列值，MySQL 必须为外层每一行都重新执行一次子查询。这不是 Navicat 的问题，而是 SQL 语义决定的——但 Navicat 的执行计划视图会把每次调用都单独列出来，看起来像“重复”，实则是 N 次调用（N = 外层扫描行数）。
例如：SELECT id, (SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id) cnt FROM users u，如果 users 表扫描了 1000 行，执行计划就会显示 1000 次 DEPENDENT SUBQUERY 条目，且 rows 列会累加体现总扫描量。
- 检查
select_type列是否为DEPENDENT SUBQUERY或DEPENDENT UNION - 用
JOIN重写等价逻辑（如把子查询转成左连接 + 聚合）可消除依赖性 - 确认外层
WHERE是否过滤不足，导致驱动表过大；加索引缩小外层扫描行数最直接 - PostgreSQL 用户注意：
LATERAL是显式支持相关子查询的语法，但执行计划仍会展开为多次调用
Navicat 自动补全或格式化引发隐式重写
某些版本的 Navicat（尤其是 15.x 及更早）在点击“解释”前，会自动对 SQL 做轻量级重写：比如把 IN (subquery) 拆成临时表，或把 NOT EXISTS 转成反向 LEFT JOIN。这些改动可能让优化器选择完全不同的路径，甚至触发本不该出现的物化（MATERIALIZED）或缓存行为，导致子查询在执行计划中“多出一帧”。
- 对比原始 SQL 与 Navicat 实际发送的语句：打开
工具 → 选项 → 其他 → 显示查询日志，勾选后重试 - 禁用自动格式化：
工具 → 选项 → SQL 编辑器 → 取消勾选“粘贴时自动格式化” - 避免在子查询内使用用户变量（如
@var:=@var+1），Navicat 可能无法正确传递会话上下文
真正难排查的是那种“执行计划里子查询出现两次，但日志只记录一次请求”的情况——这通常意味着 Navicat 内部用了预编译 + 执行计划缓存双通道，而你看到的只是渲染层合并后的视图。此时别信界面，抓包或开 MySQL general_log 才是唯一真相。
