PostgreSQL开发怎么找回历史执行记录_Navicat特有功能实操-navicat-PHP中文网

Navicat 的历史 SQL 记录仅保存在本地客户端的 History 子目录中，为加密二进制格式，不上传服务器、不写入数据库；PostgreSQL 服务端需主动启用 pg_stat_statements 或 log_statement 才能获取统计性或全量执行信息。

navicat 本身不依赖 postgresql 的系统表或日志来存执行记录——它只在本地缓存，且默认开启自动保存。关键点：这些记录 不上传服务器、不写入数据库、不随 pg_log 走，纯客户端行为。

实操建议：

navicatmysql

Navicat For MySQL

下载

记录默认保存在 Navicat 安装目录下的 History 子目录（Windows 路径类似 C:\Users\{user}\Documents\Navicat\MySQL\History，注意：即使连的是 PostgreSQL，路径里仍可能显示 MySQL，这是 Navicat 旧版命名残留，别被误导）
文件是加密的二进制格式，不能直接用文本编辑器打开；但 Navicat 自带「历史记录」面板可查看（菜单栏 → 工具 → 历史记录，或快捷键 Ctrl+Shift+H）
如果清空过 Navicat 缓存、重装过软件、或勾选过「退出时清除历史」，记录就永久丢失，pg_stat_statements 或 pg_log 都救不回来

有，但不是“谁什么时候执行了哪条 SQL”的完整回放，而是统计性、采样式、需主动启用的运行时数据。

实操建议：

先确认 pg_stat_statements 扩展是否已加载：执行 SELECT * FROM pg_extension WHERE extname = 'pg_stat_statements';，若无结果，需由 superuser 运行 CREATE EXTENSION pg_stat_statements;
该扩展默认只记录执行次数、总耗时、平均耗时、最慢一次耗时等聚合指标，不保存原始 SQL 文本的完整历史（除非配置了 pg_stat_statements.track 为 all，且 pg_stat_statements.save 为 on）
即使开启，SQL 文本会被参数化（如 WHERE id = $1），真实值不保留；且记录会随服务重启或手动调用 pg_stat_statements_reset() 清零
日志方式（log_statement = 'all'）能记全量，但会产生海量文件，影响性能，且需提前配置——事后无法补录

不是 PostgreSQL 出问题，全是 Navicat 客户端侧的隐性开关或路径变更导致。

实操建议：

检查 Navicat 设置 → 工具 → 选项 → 环境 → 「退出时清除历史记录」是否被意外勾选（尤其升级后默认可能变更）
多用户共用一台电脑时，Navicat 可能读错配置路径：比如当前登录用户是 userA，但 Navicat 启动时读取了 userB 的 History 目录（因权限或注册表残留），导致看不到自己的记录
使用便携版 Navicat 时，History 目录默认在程序同级，而非用户文档目录；换机器或重装就丢
macOS 上注意 Spotlight 或 Time Machine 是否排除了 ~/Library/Application Support/PremiumSoft/Navicat/，备份失效也会导致丢失

靠不住任何一个单独组件。真要可靠追溯，必须组合设计。

实操建议：

Navicat 仅作日常调试辅助，定期导出历史记录：打开「历史记录」面板 → 右键 → 「导出到 SQL 文件」，生成带时间戳的 navicat_history_20240520.sql，手动存 Git 或共享盘
PostgreSQL 侧至少启用 pg_stat_statements 并设置 track_utility = off（避免记录 VACUUM 等干扰项），再配合 cron 每小时跑一次 SELECT query, calls, total_time FROM pg_stat_statements ORDER BY last_call DESC LIMIT 100; 写入外部日志
敏感操作（如 DDL、大表 DELETE）务必走变更工单流程，用脚本执行而非直接粘贴——这样执行痕迹天然落在脚本版本和 CI 日志里，比任何 GUI 历史都可靠

真正难的从来不是“怎么找”，而是“谁在什么上下文里改了什么”——Navicat 记不住上下文，PostgreSQL 默认也不记人。留痕这件事，得从执行动作的设计源头卡住。