红色填充节点代表最耗时，即实际耗时占比超30%总执行时间的运算符，常见于Nested Loop、Hash Join、Sort或Materialize等操作。
Navicat 17 图形化执行计划里，哪类节点代表最耗时？
不是看“Cost”或“Estimated Rows”，而是盯住红色填充的节点——Navicat 17+ 对 PostgreSQL 和 SQL Server 的图形计划中，会自动将实际耗时占比超过 30% 总执行时间的运算符渲染为红色实心填充。MySQL 的图形计划不支持该标记，但 Navicat 17 对 MySQL 仍会高亮 type = ALL 或 Extra = Using filesort 的行。
常见红色节点包括：
- Nested Loop（尤其当右侧输入行数极大）
- Hash Join（Build 阶段内存占用突增）
- Sort 或 Materialize（实际耗时远超预估）
鼠标悬停看不到耗时数据？检查这三处硬性前提
红色节点不会凭空出现，必须满足：
- PostgreSQL：必须执行
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)，纯EXPLAIN或EXPLAIN VERBOSE不触发图形解析 - SQL Server：连接属性 → “常规”页底部必须勾选
显示执行计划，且 SQL Server 实例需支持 XML 输出（2005 及更早版本不支持） - MySQL：Navicat 17 默认调用
EXPLAIN FORMAT=TREE（8.0.16+）或EXPLAIN FORMAT=JSON，若服务端版本
为什么“Query cost (relative to batch)”不能直接信？
这个百分比只在 SQL Server 图形计划右上角出现，但它反映的是优化器预估成本占比，不是真实耗时。常见误导场景：
- 某条语句
Query cost显示 92%，但实际执行仅 80ms —— 因为整批只含一条语句，它“吃掉全部预算”但本身并不慢 - 同一语句两次执行，
Query cost从 45% 升到 78%，但Actual Total Time反而下降 —— 说明其他语句被优化得更快，拉高了相对占比 - SQL Server 中，
Query cost超过 80% 才值得优先优化，低于此值时应优先看红色节点或粗箭头流量
粗箭头比红色节点更早暴露性能地雷
图形计划中连接两个节点的粗箭头表示该步骤输出的实际行数。它比颜色标记更底层、更难掩盖：
- 左侧是
Index Seek，右侧连着Clustered Index Scan且箭头极粗 → 外层只返回 1 行，内层却扫了 50 万行，说明关联条件未走索引 -
Hash Match左侧箭头细、右侧箭头极粗 → Build 输入小、Probe 输入巨大，Hash 表构建快但探测慢，应检查 Probe 端是否缺索引 - 箭头旁标注
Actual Rows: 1234567但Estimate Rows: 100→ 统计信息严重过期，ANALYZE TABLE或UPDATE STATISTICS比改 SQL 更有效
真正容易被忽略的，是粗箭头和红色节点同时出现的位置——那里往往藏着复合问题：既缺索引，又触发了低效算法，还放大了统计误差。别只点“解释”看一眼就关掉，把鼠标悬停在粗箭头起点，记下它的 Node ID，再切到对应节点看 Actual Rebinds 和 Actual Rewinds 次数，才能确认是不是循环嵌套导致的指数级开销。
