navicat 17不支持分布式查询分析，其explain功能仅适用于单库连接下的本地查询，无法获取跨分片的真实执行计划、网络耗时、合并开销等关键信息。
Navicat 17执行计划不支持分布式查询分析
Navicat 17 的 EXPLAIN 功能仅作用于单库连接下的本地查询，它调用的是 MySQL、PostgreSQL 等单实例数据库原生的 EXPLAIN 命令。如果你的“分布式查询”指跨多个物理数据库（如分库分表中间件 ShardingSphere、MyCat，或应用层路由到不同 MySQL 实例），Navicat 根本无法生成完整执行计划——它连目标语句发往哪个节点都不知道。
常见错误现象包括：
- 你在 Navicat 中连接的是中间件虚拟库，执行
EXPLAIN后只看到中间件返回的简单提示（如sharding: route to ds_0），没有真实扫描行数、索引使用等细节 - 你手动连到某个分片库执行
EXPLAIN，但该语句在实际场景中根本不会单独跑在那里，优化结果不具备代表性 - Navicat 的可视化执行计划图里出现 “Unknown operator” 或空白节点，本质是中间件未透传底层计划
真正要调优分布式查询，得绕过Navicat查真实节点
必须把查询拆解，定位到具体分片节点上做分析。操作路径很明确：
- 先从应用日志或中间件监控（如 ShardingSphere-UI 的
SQL audit）拿到最终路由后的 SQL 和目标数据源（例如ds_1.orders） - 在 Navicat 中新建一个**直连该分片库**的连接（不是中间件地址），然后粘贴路由后的语句，再点
解释 - 重点关注
type是否为ALL、key是否为空、rows是否远超预期——这些才是真实瓶颈 - 如果涉及 JOIN 多个分片表（如广播表关联），需分别对每个参与表的分片执行
EXPLAIN，再人工比对驱动表选择是否合理
Navicat 17导出的执行计划CSV对分布式场景基本无效
你导出的 20260907_orders_join_explain.csv 只反映单节点行为，而分布式查询的性能杀手往往藏在别处：
- 网络往返：Navicat 完全不记录跨节点 RPC 耗时，
rows看着正常，但实际花了 800ms 在网络上传输 5 万行 - 合并开销：中间件需要对 8 个分片结果做
ORDER BY + LIMIT合并，这个动作 Navicat 的EXPLAIN根本不体现 - 统计信息偏差：各分片表的
ANALYZE TABLE状态不一致，导致同一语句在不同分片上选错执行路径，但 Navicat 导出的 CSV 文件之间无法自动对齐字段含义
想追踪这类问题，必须用中间件自带的执行轨迹（如 ShardingSphere 的 sql.show + props.sql-show=true）或在分片库侧开启 performance_schema.events_statements_history_long 抓真实耗时。
容易被忽略的关键点
分布式环境下，Navicat 的执行计划只是拼图的一角。最常被跳过的动作是：没确认中间件是否开启了 sql.show 或 sql.audit，就直接在 Navicat 里点 解释；没核对分片键值分布是否倾斜，就根据单个分片的 rows=100 判断查询高效；还有人把 固定查询结果 当成执行计划快照——它只存数据，不存 EXPLAIN 表格，关掉标签页就彻底丢失。
