Navicat 15 默认仅以表格形式展示 MySQL 执行计划，不支持 FORMAT=JSON 解析与图形化渲染；v16 起支持 EXPLAIN FORMAT=JSON 并解析 key_length、filtered 等字段，但仍无法图形化，且 SQL Server 和 PostgreSQL 均无可视化节点图，需升级至 v17 才具备完整图形执行计划能力。
Navicat 15 和 16 的执行计划展示形式差异，核心原因不是 UI 改动，而是底层驱动对数据库方言和执行计划协议的支持能力不同——尤其在图形化渲染、字段默认可见性、JSON 解析逻辑上，两者有实质性断层。
MySQL 执行计划：v15 默认只显示表格，v16 开始支持 FORMAT=JSON 渲染
Navicat v15 对 MySQL 的 EXPLAIN 命令默认发的是传统语法（EXPLAIN SELECT ...），返回纯表格结构，不带嵌套节点或运算符图标；v16 起（特别是 v15.5+ 后续小版本）才开始默认尝试 EXPLAIN FORMAT=JSON，并能解析出 used_indexes、key_length、filtered 等关键字段。但这个行为依赖两个前提：
- MySQL 版本 ≥ 5.6（否则
FORMAT=JSON报错） - 连接配置里未手动禁用 JSON 解释（某些企业定制版 Navicat 会关闭该选项）
- v15 即使收到 JSON 响应，也只会当普通文本显示在 Messages 标签页，不会绘制成图形流程图
SQL Server 执行计划：v16 仍不支持图形化，仅文本 XML 或 SHOWPLAN_TEXT
SQL Server 的图形化执行计划依赖客户端解析 SET STATISTICS XML ON 返回的 XML，并调用本地渲染引擎。Navicat v16 官方文档和实测均确认：它不具备该渲染能力，只做基础 XML 展示或降级为 SET SHOWPLAN_TEXT ON 的纯文本。真正支持图形化的是 v17（2026 年初发布）——v16 用户点“解释”后看到 XML 内容却无图，不是操作问题，是功能缺失。
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
- 验证方式：把同一条 SQL 粘进 SSMS，按
Ctrl+M；若 SSMS 也不出图，说明服务端不支持（如 SQL Server 2005） - v16 遇到不兼容语法（如
INSERT EXEC、OPENQUERY）时，会静默切换回文本模式，且不提示降级 - XML 中若含非标准 UTF-8 字符（比如从日志复制的带 BOM 的 SQL），v16 渲染器可能直接崩溃，导致执行计划窗口空白
PostgreSQL 执行计划：v15/v16 都不支持可视化节点图
PostgreSQL 的图形化执行计划需要完整解析 EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) 输出，并依赖 track_activities=on 和 track_counts=on 这两个参数开启统计收集。Navicat v15 和 v16 均未实现该解析链路——它们只把结果当表格渲染，即使你手动写全命令，也看不到高亮耗能节点或内存分配提示。
- v16 比 v15 多一个改进：能正确识别
Buffers:行并计入统计，但依然不画图 - 如果 PostgreSQL 服务端没开
track_io_timing=on，v16 的 “I/O Time” 列会始终为 0，容易误判磁盘瓶颈不存在 - 别信 v16 界面右上角显示的“执行耗时”，那是 Navicat 自己计时（网络+解析+传输），不是数据库真实
Execution Time
为什么右键执行计划表格看不到 key_len 和 ref？
Navicat v15 默认只显示 id、select_type、table、type、possible_keys、key 这 6 列，而判断是否真走索引的核心依据 key_len 和 ref 被隐藏了。v16 仍延续此设计，必须手动展开：
- 右键执行计划结果表格 → 选「显示所有列」
-
key_len = 0且ref = NULL同时成立，基本确认没走任何索引 - v16 不会自动补全
EXTRA列里的Using index condition或Using MRR，这些得靠你肉眼扫 Messages 里的原始 EXPLAIN 输出
真正影响判断的不是版本号本身，而是你连的是什么数据库、服务端开了哪些参数、以及 Navicat 实际发了哪条命令——v16 看似比 v15 “多一点”，但它对图形化、深度字段、实时统计的覆盖仍是碎片化的。想稳定看到图形节点图，目前唯一路径是升级到 v17，并确认目标数据库版本和权限配置已就位。
