Navicat 17 可视化执行计划中红色代表最高预估成本节点，橙→黄→绿渐变表示成本占比递减；颜色基于优化器估算而非实际耗时，需开启Show Actual Execution Stats等三项设置才能准确反映真实瓶颈。
执行计划里哪些颜色代表高成本操作
navicat 17 的可视化执行计划默认用红→橙→黄→绿渐变色标示节点开销占比，红色节点即为相对总成本最高的执行步骤，不是绝对耗时，而是该节点预估成本占整个计划的百分比权重。比如 seq scan 节点显示深红色，说明它可能是全表扫描且未命中索引；而 index scan 显示浅黄色，通常表示索引利用良好、数据集小或筛选条件高效。
注意：颜色只反映优化器估算值，不等于真实耗时。若实际慢但颜色偏绿，大概率是统计信息过期（VACUUM ANALYZE 未执行）或绑定变量导致计划失真。
为什么“Nested Loop”常被标红却不一定真慢
Navicat 17 对 Nested Loop 节点倾向标红，因为它在估算中假设内层循环会重复多次——但现实中如果外层结果集极小（如 WHERE id = ?），实际开销可能远低于估算。这时要结合“Rows Removed by Filter”和“Actual Total Time”字段交叉验证：
- 若
Rows Removed by Filter数值极大，说明 WHERE 条件没走索引，过滤靠 CPU 拷打，必须优化谓词 - 若
Actual Total Time远低于Planning Time，说明计划生成阶段就卡住了，可能是统计信息陈旧或work_mem不足 - PostgreSQL 用户特别注意：当出现
Nested Loop + Materialize组合且标红，大概率是子查询未内联，可尝试加/*+ SET(enable_material OFF) */提示强制重写
如何让颜色提示真正有用——三个必调设置
默认配色容易误判，尤其在多层嵌套或并行查询中。必须手动打开三项关键开关：
- 勾选
Show Actual Execution Stats（右键执行计划图 → “刷新执行统计”），否则所有颜色都基于估算，无参考价值 - 在连接属性 →
Advanced页中启用track_io_timing = on和track_activity_query_size = 4096，否则 I/O 等待无法体现在节点颜色中 - 对 MySQL 连接，需确认
performance_schema已开启，且 Navicat 连接字符串包含?useSSL=false&allowPublicKeyRetrieval=true，否则无法获取EXPLAIN FORMAT=JSON的完整字段
达梦/金仓等国产库的执行计划颜色异常怎么办
Navicat 17.3 对达梦 DM8+、金仓 KingBaseES 的执行计划解析仍依赖数据库返回的文本格式，其原生计划树结构与 PostgreSQL/MySQL 不兼容，会导致颜色映射错位——例如本该标红的 TABLE SCAN 可能显示为绿色。
临时解法只有两个：
- 切换到
Text Plan标签页，人工查找含 “FULL SCAN”、“NO INDEX”、“FILTER: true” 的行 - 在 SQL 编辑器中手动执行原生命令：
EXPLAIN PLAN FOR SELECT ...（达梦）或EXPLAIN (ANALYZE, BUFFERS) SELECT ...（金仓），把输出粘贴进 Navicat 的“SQL 调试窗口”再看颜色
真正的瓶颈往往藏在国产库特有的执行算子名里，比如达梦的 JOIN HASH BUILD 或金仓的 SEQSCAN WITH FILTER，这些不会被 Navicat 的通用着色逻辑识别，得靠人眼盯住关键词。
