Navicat 没有 SQL 工作簿功能，所谓“工作簿”实为对查询标签页的误解；应通过命名 SQL 文件、配套 Markdown 记录、索引 DDL 对比及手动采集执行耗时等方式实现可追溯的问题排查过程。
sql工作簿 不是 navicat 的功能模块，navicat 没有 sql 工作簿这个东西。你看到的可能是混淆了其他工具（如 azure data studio 的 notebook、dbeaver 的 sql 编辑器标签分组、或 jupyter + sql 插件），或者误将 navicat 的「查询文件」+「标签页」+「历史日志」组合当成了结构化的工作簿。
如果你的目标是用 Navicat 协助团队记录问题排查与解决过程（比如“为什么这个查询变慢了？怎么改的？效果如何？”），那得绕开“工作簿”这个不存在的概念，转而用真实可用、可协作、可追溯的组合方式。
为什么不能把多个标签页当工作簿用
Navicat 的查询编辑器标签页本质是临时会话容器：
• 未保存的标签页（如 Untitled-1）不会同步到 Navicat Cloud，关掉就丢
• 多人同时编辑同一张表的多个查询标签，没有任何版本提示或冲突标记
• 标签页之间无法添加说明性文本、时间戳、执行结果截图或前后对比注释
• 导出时只能单个导出为 .sql，不带上下文元数据
真正能落地的“问题过程记录”做法
用 Navicat 做记录，核心是把「操作动作」和「决策依据」分离存储，靠外部约定补全缺失环节：
- 所有分析语句必须存为命名文件：比如
20260528_orders_slow_explain.sql，路径统一放在团队 Git 仓库的/sql-debug/下 - 每次执行
EXPLAIN后，立刻复制结果网格（右键 → Copy as → Grid），粘贴进同名 Markdown 文件（如20260528_orders_slow_explain.md），加一行说明：“索引缺失，type=ALL，rows=247K” - 修改索引前，用 Navicat「设计表 → 索引」右键导出原索引 DDL 到
_before_index.sql；建完再导一次存为_after_index.sql - 变更后跑对比查询，把 Navicat 查询编辑器底部的状态栏耗时（如
Query took 3.248 sec）手动记入 Markdown，别信“执行时间”面板里那个浮动数字——它不含网络延迟
Navicat 历史日志（Ctrl+H）能帮你什么，不能帮你什么
它的作用非常有限，但有唯一不可替代的价值：
- ✅ 能查到「谁在什么时候执行了哪条语句」——前提是所有人用各自独立数据库账号登录（不是共用
app@%） - ✅ 日志文件路径明确：
%AppData%\Navicat\MySQL\servers\[连接名]\LogHistory.txt（Windows），可写脚本定期归档 - ❌ 不记录语句执行结果、返回行数、警告信息（比如
Truncated incorrect DOUBLE value） - ❌ 不记录是否在事务中执行、是否被自动回滚、是否触发了触发器
- ❌ 如果某人用「编辑记录」界面点对号更新数据，这条 DML 完全不会出现在历史日志里
真正容易被忽略的点在于：你以为把三段 SQL + 一张 EXPLAIN 截图发到群里，就完成了“过程记录”。其实漏掉了最关键的三个锚点——执行时的并发负载（SHOW PROCESSLIST 快照）、锁等待状态（SELECT * FROM performance_schema.data_lock_waits）、以及 buffer pool 命中率变化（需 SHOW ENGINE INNODB STATUS 解析）。这些 Navicat 一个都抓不到，必须靠 Navicat Monitor 或命令行配合。
