Navicat 17 无法自动对比执行计划，因其仅调用原生 EXPLAIN 渲染表格，不保存历史、不关联语句、不语义对齐；两个计划完全独立，表别名错位、JOIN顺序不同、rows估算浮动，导致人工硬对易错，需手动开双窗口并列查看并聚焦type/key/Extra等核心字段。
Navicat 17 无法自动对比执行计划，必须靠人工并列观察 + 关键字段横向比对——它没有“差异高亮”或“结构化 diff”功能。
为什么不能直接点一下就出对比结果
Navicat 17 的“解释”功能只是调用数据库原生 EXPLAIN 并渲染成表格，每次点击都生成全新快照，不保存历史、不关联语句上下文、也不做字段语义对齐。两个执行计划表格哪怕结构一致，也完全独立：表别名可能错位、JOIN 顺序不同导致行序颠倒、rows 值受采样影响浮动——你看到的“同一行”，实际可能对应不同子查询。
常见错误现象包括：
- 点了两次“解释”，但第二个覆盖了第一个标签页，误以为在对比，其实只看了一个
- 用“固定查询结果”留住了数据结果，却忘了执行计划表格本身不会被固定
- 导出两个
.csv文件后在 Excel 里按行号硬对，结果table = 'orders'那行在文件 A 是第 3 行，在文件 B 是第 5 行，手动拖拽半天对错了
手动并排查看执行计划的实操步骤
最可靠的做法是让两个执行计划表格同时可见，并聚焦核心字段：
- 开两个独立 Navicat 查询窗口（不是两个标签页），粘贴两条待比对的 SQL，分别点“解释”
- 确保两个窗口都切到“解释”标签页，再用系统快捷键（Windows 下
Win + ←/Win + →）并列铺开 - 关闭所有无关列，只保留：
id、select_type、table、type、key、rows、Extra - 重点盯住三组变化：
type是否从ALL变成ref；key是否从NULL变出具体索引名；Extra是否去掉Using filesort或Using temporary
MySQL 8.0+ 用户注意 optimizer_trace 必须开启
Navicat 17 的图形化执行计划依赖 MySQL 的 optimizer_trace 功能，如果没开，你看到的可能是空表或只有基础字段。检查方式：
- 连接属性 → “高级”选项卡 → 确认勾选了“使用优化器跟踪”
- 若仍为空，手动执行
SET optimizer_trace="enabled=on";再试一次“解释” - PostgreSQL 用户需删掉语句末尾的分号（
;），否则EXPLAIN返回空
比对时最容易被忽略的细节
执行计划不是静态快照，而是优化器基于当前统计信息、缓存状态、甚至临时表存在与否做的即时决策。所以：
- 不要在两次解释之间切换其他查询或执行 DML，避免
information_schema统计刷新干扰 - 如果第一条语句用了临时表，第二条没建，那
type = DERIVED和type = SIMPLE的差异就不是 SQL 问题，而是环境不一致 -
rows值在 MySQL 中是估算值，波动 ±30% 正常；真正该比的是rows_examined（需查performance_schema.events_statements_history_long）
真要长期追踪计划变化，得绕过 Navicat，用脚本定期跑 EXPLAIN FORMAT=JSON 存进自建表——Navicat 本身只负责“看一眼”，不负责“记一笔”。
