Navicat 17 执行计划中连线粗细代表预估行数（rows）的相对比例，越粗表示输出数据量越大；仅 MySQL、MariaDB、PostgreSQL 支持，依赖其 JSON 格式 EXPLAIN 中的 rows 字段。
Navicat 17 的执行计划连线粗细代表什么
navicat 17 的「可视化查询解释」中，连线粗细不是随意渲染的视觉效果，而是直接映射 rows（预估返回行数）的相对比例。越粗的线，说明该节点输出的数据量越大；越细，说明中间结果集被显著过滤或聚合压缩了。
这个设计意图很明确：帮你一眼识别数据膨胀点或性能瓶颈位置。比如一个 Nested Loop 节点连出两条线，其中一条极粗、另一条极细，大概率意味着外层循环驱动了大量重复扫描——这时候就要检查是否缺索引，或是否该用 Hash Join 替代。
哪些数据库支持粗细连线，哪些不支持
目前只有 MySQL、MariaDB 和 PostgreSQL 的执行计划能渲染带粗细的连线。这是因为 Navicat 依赖这些数据库原生 EXPLAIN FORMAT=JSON 或 EXPLAIN (ANALYZE, FORMAT JSON) 中的 rows 字段做归一化计算。
SQL Server、Oracle、Snowflake 等暂不支持该特性，它们的可视化执行计划仍为等宽连线，仅靠颜色或图标区分操作类型。
- MySQL 5.7+ 和 8.0：需开启
optimizer_trace或确保EXPLAIN返回完整 JSON - PostgreSQL 12+：必须使用
EXPLAIN (ANALYZE, FORMAT JSON)，仅EXPLAIN文本格式无法提取行数 - MariaDB 10.4+：要求启用
optimizer_switch='explain_format=json'
连线粗细不准的常见原因
如果你看到明显反直觉的粗细（比如 WHERE id = ? 连线比全表扫描还粗），大概率是统计信息过期或估算机制失效导致的 rows 值失真，而非 Navicat 渲染错误。
- PostgreSQL 没运行
ANALYZE，导致 planner 用默认基数（通常是 1000 行）估算 - MySQL 的
innodb_stats_persistent关闭，且表数据变动大但没触发自动重采样 - 查询含复杂表达式（如
JSON_EXTRACT、正则匹配），优化器无法准确估算选择率 - Navicat 解析 JSON 时遇到嵌套过深或字段缺失，回退到固定权重值（此时会显示警告图标）
怎么验证某条连线的数值依据
把鼠标悬停在任意连线末端（即箭头起点或终点）上，会弹出 tooltip，显示该边对应的节点名称 + 「Rows: XXX」。这个 XXX 就是 Navicat 用来计算粗细的原始值。
想进一步确认，可右键点击执行计划画布 → 选择「查看原始 EXPLAIN JSON」，在弹出窗口里搜索对应节点的 rows 或 estimated_rows 字段。注意：不同数据库字段名不同，PostgreSQL 是 Plan Rows，MySQL 是 rows，MariaDB 可能是 filtered × rows 的乘积。
真正容易被忽略的是：Navicat 对粗细做了对数归一化（非线性缩放），所以 10 行和 100 行的视觉差异，远小于 1000 行和 10000 行的差异——别拿尺子去量像素。
