Navicat历史记录消失是因异常退出导致history.db处于WAL日志不一致或事务未提交状态，并非数据被删；需关闭所有实例、备份并重命名history.db及相关文件后重启，新记录将重新生成。
Navicat 历史执行记录消失，history.db 文件还在但不显示
navicat 的历史 sql 记录不是实时写入数据库的，而是缓存在内存中、定期刷盘。如果异常退出（比如崩溃、强制杀进程），history.db 可能处于半损坏或事务未提交状态，导致重启后记录“凭空消失”。这不是数据被删了，而是 sqlite 无法安全读取当前文件头或 wal 日志不一致。
实操建议：
- 先关闭所有 Navicat 实例（包括系统托盘残留进程）
- 定位缓存目录：
~/Library/Application Support/PremiumSoft CyberTech/Navicat for MySQL/（macOS）、%APPDATA%\PremiumSoft\Navicat for MySQL\（Windows）——注意路径里带版本号（如Navicat for MySQL 16.0） - 找到
history.db和同目录下的history.db-wal、history.db-shm（如果有），**一起重命名备份**，例如改为history.db.bak、history.db-wal.bak - 重启 Navicat，它会自动生成新的
history.db；旧记录不会自动恢复，但新执行的 SQL 会重新开始记录
想恢复旧记录？别直接用 SQLite 工具打开 history.db
直接用 DB Browser for SQLite 或命令行 sqlite3 history.db .dump 很可能报错 database disk image is malformed，因为 Navicat 使用了自定义 page size 和 journal mode（通常是 WAL），且可能启用了加密扩展（虽不默认启用，但部分企业版或旧版本有混淆逻辑）。
实操建议：
- 确认是否真有必要恢复——Navicat 历史记录默认只存最近 1000 条，且不包含执行时间戳、结果集，价值有限
- 若坚持尝试：用 Navicat 同版本的
sqlite3命令行工具（它自带 patched 版本），路径通常在安装目录内，比如navicat.app/Contents/Frameworks/sqlite3（macOS） - 运行
./sqlite3 history.db "PRAGMA integrity_check;"，若返回ok，再查表：SELECT sql FROM sqlite_history ORDER BY id DESC LIMIT 20;（表名可能是sqlite_history或history，需先.tables确认）
重置历史记录后仍不生效：检查 navicat.ini 中的 EnableHistory
Navicat 的历史开关不是纯 UI 控制，底层靠配置文件硬开关。即使界面上勾选了“启用历史记录”，若 navicat.ini 里 EnableHistory=0，它就完全不写入任何东西——连新建的 history.db 都是空的。
实操建议：
- 在同级缓存目录下找
navicat.ini（不是注册表！Windows/macOS 都是文件） - 搜索
EnableHistory，确保其值为1；若不存在，手动添加一行：EnableHistory=1 - 同时检查
HistoryMaxCount（默认 1000），数值过小会导致刚执行几条就覆盖掉前面的 - 修改后必须彻底退出 Navicat 再启动，热加载不生效
Mac 上用 Time Machine 恢复过整个 Navicat 目录，结果历史记录更乱了
Time Machine 备份的是某个时间点的完整快照，但 history.db 是持续追加写入的。如果你从三天前的备份恢复，而 Navicat 本地又生成了新记录，SQLite 的 WAL 日志和主文件版本就会严重错位，轻则启动卡死，重则下次启动直接清空 history.db 并新建。
实操建议：
- 避免整目录恢复 Navicat 缓存数据；只恢复明确需要的单个文件（如连接配置
connections.ncx） - 若已出问题：删掉整个缓存目录（保留
connections.ncx单独备份），让 Navicat 重建环境——比修一个错位的 SQLite 更可靠 - 长期建议：用 Navicat 自带的“导出连接”和“导入连接”，而不是依赖文件级备份
真正麻烦的不是找不到记录，而是误以为 history.db 是标准 SQLite 数据库——它受 Navicat 运行时状态强约束，脱离上下文就容易变砖。备份时盯住 connections.ncx 和手写的 SQL 脚本，比抢救 history.db 实用得多。
