Navicat点击“解释”按钮默认发送基础EXPLAIN语句，PostgreSQL v16+虽显示为EXPLAIN (ANALYZE, BUFFERS)，但实际禁用ANALYZE与BUFFERS，等效于EXPLAIN；如需VERBOSE、ANALYZE或JSON格式等完整信息，必须手动改写SQL。
navicat 默认不执行 explain verbose，必须手动改写 sql 才能拿到完整字段级信息。
Navicat 点“解释”按钮实际运行的是什么
Navicat for PostgreSQL（v16+）点击“解释”时，默认发送的是 EXPLAIN (ANALYZE, BUFFERS)，但会自动禁用 ANALYZE（避免真实执行），最终等效于 EXPLAIN 基础模式。它不会加 VERBOSE、COSTS 或 SETTINGS，所以看不到函数内联展开、计划节点的字段来源、隐式类型转换细节等关键诊断信息。
- 想看字段是否来自索引还是堆表扫描，必须显式加
VERBOSE -
ANALYZE被禁用是安全策略，但代价是缺失实际行数、启动/总耗时、缓冲区命中率等运行时数据 - 如果你连的是只读用户或权限受限实例，
BUFFERS可能直接报错：ERROR: permission denied for function pg_stat_get_backend_pid
怎么手动触发 EXPLAIN VERBOSE 并正确查看结果
不能依赖“解释”按钮——得自己写、自己跑：
- 在查询编辑器中，把原始 SQL 包裹成：
EXPLAIN (VERBOSE, FORMAT JSON) SELECT ...
（推荐FORMAT JSON，结构清晰，方便复制到外部工具解析） - 如果只要表格化输出，用：
EXPLAIN (VERBOSE, FORMAT TEXT) SELECT ...
，但注意 Navicat 会把多行文本当单字段展示，需右键单元格 → “在新窗口中查看大文本” - 别用
FORMAT YAML：Navicat 渲染 YAML 会乱码或截断，且无法折叠层级 - 执行后结果直接显示在“查询结果”标签页，不是“执行计划”专用视图——这点和 MySQL 模式不同
常见误操作与对应现象
很多人以为点一下“解释”就万事大吉，结果漏掉关键线索：
- 看到
Seq Scan就以为没走索引，但EXPLAIN VERBOSE可能显示Output: id, name全部来自索引覆盖（Index Only Scan），只是 Navicat 默认模式不告诉你字段来源 - 执行计划里出现
Filter: (some_func(col))，但不知道some_func是否被内联；加VERBOSE后能看到Node Type: Function Scan或直接消失（说明已内联） - 用
EXPLAIN (ANALYZE, VERBOSE)报错？检查用户是否有pg_read_all_stats角色，或换用只读用户允许的EXPLAIN (VERBOSE) - 字段别名在
VERBOSE输出中会变成Output: (col1 + col2) AS sum_val，但默认模式只写Output: sum_val，丢失表达式上下文
为什么不用 Navicat 内置“执行计划”视图看 VERBOSE 结果
因为 Navicat 的图形化执行计划视图（带树形节点、耗时条、箭头连线的那个）只解析标准 EXPLAIN 文本格式，不支持 VERBOSE 字段扩展，更不解析 JSON/YAML。你手动加了 VERBOSE，它就退化为纯文本展示，图形界面自动关闭。
- 想兼顾可读性与完整性：用
EXPLAIN (VERBOSE, FORMAT JSON)+ 复制结果到 VS Code 安装JSON Tools插件格式化查看 - 生产环境排查时，优先保存
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)结果（需权限），它包含真实 I/O 和内存行为，比预估计划更有说服力 - Navicat Monitor 的“SQL 性能分析工具”能自动采集带
VERBOSE的计划，但前提是 PostgreSQL 已启用pg_stat_statements并配置了足够长的track_activity_query_size
真正卡住性能的往往不是扫描方式，而是字段计算逻辑是否下推、函数是否内联、表达式是否可索引——这些全藏在 VERBOSE 输出里。别省那几秒手敲 (VERBOSE) 的功夫。
