navicat“解释”功能仅格式化数据库原生explain结果，不自行分析；要看真实执行计划需手动用explain analyze（pg）或explain format=json（mysql），并重点关注type、key、rows、extra等关键列。
navicat 的“解释”功能本质是调用数据库原生的 explain（或 explain analyze），它不自己分析，只把执行计划结果格式化展示——所以能不能看出性能问题，取决于你是否理解执行计划里的关键字段。
怎么触发真正的执行计划（不是估算）
Navicat 默认点击「解释」按钮（⚡ 图标）时，实际发送的是 EXPLAIN，仅做语句解析和估算，不真正执行。要看到真实耗时、实际扫描行数等关键指标，必须手动改用 EXPLAIN ANALYZE（PostgreSQL）或 EXPLAIN FORMAT=JSON + 执行（MySQL 5.7+），否则容易误判。
- MySQL 用户：在查询编辑器里把
SELECT ...改成EXPLAIN FORMAT=JSON SELECT ...，再点「运行」；Navicat 不会自动帮你加FORMAT=JSON - PostgreSQL 用户：直接把
SELECT换成EXPLAIN ANALYZE SELECT，注意它会真实执行一次，慎用于写操作或大数据量查询 - SQL Server 用户：Navicat 调用的是
SET STATISTICS XML ON，但需确保连接权限包含SHOWPLAN，否则返回空或报错Msg 3604, Level 16
重点关注哪几列（以 MySQL EXPLAIN 输出为例）
Navicat 表格视图默认展示 12 列，但真正影响性能的就几个，其他多数是冗余信息或仅用于调试。
-
type：值为ALL（全表扫描）或index（全索引扫描）基本等于慢；优先看是否能落到range、ref或const -
key：显示实际用到的索引名；若为NULL，说明没走索引——别只看有没有possible_keys，那只是候选 -
rows：预估扫描行数；如果比表总行数还大，说明优化器判断失准，可能需要ANALYZE TABLE更新统计信息 -
Extra：出现Using filesort或Using temporary是典型性能红灯，意味着无法避免排序/临时表
为什么有时候「解释」结果和实际执行速度对不上？
根本原因是 Navicat 的「解释」依赖数据库当前统计信息和缓存状态，而这两者极易过期或失真。
- 表数据批量导入后未执行
ANALYZE TABLE（MySQL）或VACUUM ANALYZE（PostgreSQL），会导致rows严重低估 - 查询涉及子查询或 CTE，MySQL 5.7/8.0 对其
EXPLAIN支持有限，可能显示DERIVED或MATERIALIZED却不暴露内部开销 - Navicat 自身对某些数据库（如 Oracle）仅支持基础
EXPLAIN PLAN FOR，无法获取绑定变量实际值，导致执行计划与真实场景偏差
真正卡点往往不在 Navicat 界面里——比如 key_len 显示用了联合索引前两列，但第三列条件用了函数（WHERE YEAR(created_at) = 2024），索引就断了，而 EXPLAIN 不会警告这点。得结合语句重写和索引定义交叉验证。
