Navicat 16 的“解释”功能默认渲染不全，因对 MySQL 8.0+ FORMAT=tree 支持不完整导致字段错乱或丢失，PostgreSQL 需手动在连接高级设置中启用 EXPLAIN 命令；关键列如 key、rows 可能为空并非真无索引，而是解析失败，应强制使用 EXPLAIN FORMAT=TRADITIONAL 确保四列（type/key/rows/Extra）完整可读。
EXPLAIN 结果在 Navicat 16 里不是“点一下就看懂”，它默认渲染不全、字段错位、关键信息丢失——直接右键“解释”得到的执行计划，大概率让你误判索引是否生效。
Navicat 16 的「解释」按钮为什么显示不全？
Navicat 16 对 MySQL 8.0+ 默认 FORMAT=tree 的支持不完整，表格列会错乱，rows、key、possible_keys 等关键字段可能被截断或空置；PostgreSQL 则依赖连接配置是否启用 Enable EXPLAIN command（需在连接属性 → 「高级」中手动勾选）。
常见现象包括：
-
key列为空，但实际有索引可用 → 实际是FORMAT=tree导致 Navicat 解析失败 - 执行计划窗口只显示原始 SQL，无任何分析行 → 连接未开启 EXPLAIN 权限或参数
- MySQL 报错
ERROR 1064 (42000)→ 语句里混入了SET timestamp=...或跨库前缀（如db2.table），而 Navicat 在非目标库下执行EXPLAIN
务必手动加前缀：EXPLAIN FORMAT=TRADITIONAL SELECT ...，确保字段对齐、type/key/rows/Extra 四列可读。
怎么看懂 Navicat 里显示的 type/key/rows/Extra？
别只盯 type=ALL —— 它确实是危险信号，但更隐蔽的问题藏在其他组合里：
-
type=ref且rows=500000，但结果只有 10 行 → 索引字段顺序不匹配 WHERE 条件最左前缀，或数据倾斜严重（如status='done'占 90% 行） -
key有值，possible_keys更多 → 优化器主动弃用某个索引，常因WHERE中用了函数（如YEAR(create_time)=2023）或隐式类型转换 -
Extra出现Using filesort→ORDER BY字段不在联合索引末尾；出现Using temporary→GROUP BY或DISTINCT涉及非索引字段 -
rows_examined远大于rows_sent（比如 10 万 vs 100）→ 扫描量巨大但有效数据极少，优先检查 WHERE 条件选择性
Navicat 16 查不到慢 SQL？先确认服务端有没有真在记
Navicat 本身不生成慢日志，它只是查看入口。如果你在 mysql.slow_log 表或日志文件里查不到内容，90% 是服务端没开：
- MySQL：执行
SHOW VARIABLES LIKE 'slow_query_log'，返回OFF就白搭；顺手查long_query_time，报表类查询建议设为0.5 - PostgreSQL：确认已启用
pg_stat_statements扩展，并在postgresql.conf加了shared_preload_libraries = 'pg_stat_statements' - log_output=FILE 时，Navicat 打不开日志文件 —— 必须先下载到本地，用文本编辑器打开，只复制
# Query_time:后面那行开始的纯 SQL（删掉所有#开头的注释和SET timestamp=）
别用 Navicat 的「查询分析器」找瞬时慢查询 —— 它每 5 秒轮询一次，而多数报表 SQL 耗时 800ms 就结束了，根本不在采样点上。
索引查看器 ≠ 索引生效验证器
在 Navicat 16 的「设计表 → 索引」页能看到所有索引定义，但它不会告诉你这个索引对当前 SQL 是否真被选用，也不会提示字段顺序是否覆盖 WHERE + ORDER BY 全流程：
- 你建了
INDEX(status, created_at)，但查询含ORDER BY updated_at DESC→ 执行计划里照样出Using filesort -
possible_keys有值、key为空 → 可能是优化器估算走索引比全表扫描还慢（比如WHERE status IN ('a','b','c')返回 70% 行） - 跨库查询（如
SELECT * FROM db2.orders）在非db2库下执行EXPLAIN→key列强制为空，误判“没索引”
真正要验证索引效果，得在目标库下手动跑 EXPLAIN FORMAT=TRADITIONAL，并对比 rows 和实际结果集规模 —— 差两个数量级，基本可以确定索引没走对。
