navicat 17 不保存执行计划快照，仅支持手动导出为 csv/html；“固定查询结果”不保留执行计划表格，导出前需确认当前标签页显示目标语句计划，文件名建议含时间戳和语句特征。
navicat 17 的执行计划快照保存在哪
navicat 17 不会自动持久化执行计划，解释操作生成的结果仅存在于当前标签页，关闭即丢。所谓“保存快照”，实际是手动导出为 csv/html 或复制到外部文档——它没有内置的执行计划版本库或时间轴对比功能。
你看到的“固定查询结果”按钮（固定）只保留查询返回的数据集，**不保留执行计划表格本身**。这点容易混淆，尤其当两个查询结果都点了固定，但执行计划早已刷新覆盖。
- 执行计划表格右上角有导出图标，点它可存为
.csv或.html - 导出前务必确认当前标签页显示的是目标语句的执行计划，而非其他查询的历史结果
- 文件名建议包含时间戳和语句特征，例如
20260421_1423_orders_by_status_explain.csv
用 CSV 快照做横向性能对比的实操限制
直接打开两个导出的 .csv 文件用 Excel 对比 rows、key、Extra 列，看似可行，但存在几个硬伤：
-
rows值受采样影响，MySQL 8.0+ 的EXPLAIN FORMAT=JSON才含真实扫描行数，Navicat 默认用传统格式，rows是估算值 - 同一语句在不同时间点执行，因统计信息未更新或缓存命中，
type可能从ref变成ALL，但这不代表 SQL 本身变差，而是优化器决策路径变化 - CSV 没有结构化元数据，无法自动识别哪一行对应哪个表别名，JOIN 顺序稍复杂就对不齐
所以，靠多个 CSV 文件人工比对，适合发现明显退化（比如某次 key 突然为空），但不适合定位细微波动原因。
真正能追踪执行计划波动的替代做法
如果真要监控执行计划随时间的变化，得绕过 Navicat 的 UI 层，直接落地到数据库侧：
- 在 MySQL 中启用
performance_schema并开启events_statements_history_long，配合sys.statement_analysis视图查历史执行摘要 - 用
SELECT * FROM performance_schema.events_statements_history_long WHERE sql_text LIKE '%your_query%'抽取带digest_text和first_seen的记录 - 定期跑
EXPLAIN FORMAT=JSON+SELECT组合脚本，把 JSON 结果存进自建的explain_log表，字段包括sql_digest、plan_json、exec_time_ms、collected_at
Navicat 17 的可视化解释只是个“快照查看器”，不是“计划监控器”。想看波动，得自己搭一层轻量日志管道——否则每次都要人肉导出、重命名、打开、拖拽列对齐，三天就放弃。
为什么 Navicat 17 没做执行计划版本管理
这不是疏忽，是设计取舍。Navicat 定位是交互式开发工具，不是 APM 或数据库可观测平台。它的 解释 功能本质是调用一次 EXPLAIN 命令并渲染结果，不介入查询生命周期管理。
真正的计划漂移分析需要关联：SQL 文本归一化（去掉常量）、统计信息变更时间、索引 DDL 时间、buffer pool 命中率等多维信号——这些 Navicat 不采集也不存储。它连自己的连接会话是否复用、是否走预编译都不暴露控制开关。
所以别指望靠 固定 或菜单里某个隐藏选项实现自动对比。能做的，就是导出时多写几行备注，把当时表数据量、索引状态、是否刚 ANALYZE TABLE 记下来——这部分信息，Navicat 从不帮你记。
