navicat连接代理后执行计划不准确的根本原因是代理层截断、重写或缓存explain请求，导致数据库返回的原生执行计划被篡改、降级或丢失关键字段。
navicat 连接代理（如 ssh 隧道、http 代理、或数据库中间件如 proxysql / maxscale）后执行计划不准确，根本原因不是 navicat 本身出错，而是代理层截断、重写或缓存了原始执行计划请求，导致 mysql/sql server 等数据库返回的 plan 数据被篡改、降级或丢失关键字段。
代理会干扰 EXPLAIN 请求的完整链路
数据库原生执行计划依赖精确的协议交互：MySQL 要求 EXPLAIN 或 EXPLAIN FORMAT=JSON 必须走原生 MySQL 协议；SQL Server 要求 SET SHOWPLAN_XML ON 后紧跟可执行语句，且不能被中间层拆包或缓冲。而多数代理（尤其是 HTTP 类或通用 TCP 代理）会：
- 把
EXPLAIN当作普通查询透传，但丢弃客户端设置的 session 变量（如optimizer_trace=on、innodb_stats_persistent_sample_pages），导致统计信息未生效 - 对返回的 XML/JSON 响应做字符集转换或截断（尤其当 plan 内容超 64KB），Navicat 解析时字段缺失或结构损坏
- 复用连接池中的旧连接，而该连接可能已执行过其他语句，
EXPLAIN实际查的是上一条语句的 plan 缓存（MySQL 8.0+ 的 query cache 已移除，但某些中间件仍模拟类似行为）
SSH 隧道下 rows 估算严重偏离的实际原因
SSH 隧道本身不修改 SQL，但它常伴随连接参数变更，间接触发优化器退化：
- Navicat 默认通过 SSH 连接时，会禁用
innodb_stats_persistent检测逻辑，导致 ANALYZE TABLE 后统计未落盘，rows始终基于旧采样 - 隧道延迟高 → 客户端等待超时 → Navicat 自动重试并 fallback 到
EXPLAIN文本模式（而非 JSON），丢失filtered、key_len等关键列 - 部分 SSH 代理（如某些跳板机脚本）会 strip 掉 client capability flag，使 MySQL 服务端误判为老版本客户端，禁用
FORMAT=TREE支持，Navicat 无法渲染树形结构
ProxySQL / MaxScale 等中间件导致 key 为空
这类中间件为实现读写分离或路由，会对 SQL 做 rewrite，直接破坏索引匹配条件：
- 自动添加
/*+ MAX_EXECUTION_TIME(3000) */注释 → 触发 MySQL 8.0+ 的 hint 解析 bug，优化器放弃使用统计信息，key列为空 - 重写
WHERE status = 'active'为WHERE status IN ('active')→ 表面等价，但优化器认为选择性下降，跳过索引 - 对 JOIN 查询强制添加
STRAIGHT_JOIN→ 绕过优化器 join order 评估，但 Navicat 执行计划里仍显示 type=ALL，因中间件未透传真实执行路径
怎么验证是不是代理的问题？
最直接的方法是绕过代理直连验证：
- 在同台机器用命令行工具直连（如
mysql -h127.0.0.1 -P3306 -uuser -p），执行同一句EXPLAIN FORMAT=JSON SELECT ...，对比输出是否含"query_block": {...}和"rows_examined_per_scan" - 在 Navicat 中右键选中语句 → “Explain Selected”，再打开「首选项 → 查询」→ 关闭
Use legacy explain format，避免代理二次降级 - 抓包确认：用 Wireshark 过滤 MySQL 协议，看客户端发送的 packet 是否含
COM_QUERY+EXPLAIN字符串，服务端返回的 payload length 是否与 Navicat 显示行数匹配
真正难排查的点在于：代理不报错，只静默降级——你看到的“执行计划”可能是文本格式 fallback、缓存结果，或是中间件伪造的简化版。不要相信右上角那个绿色“解释”按钮的输出，除非你确认链路里没任何中间层。
