Navicat 的历史 SQL 记录仅保存在本地客户端的 History 子目录中，为加密二进制格式，不上传服务器、不写入数据库；PostgreSQL 服务端需主动启用 pg_stat_statements 或 log_statement 才能获取统计性或全量执行信息。
Navicat 的历史 SQL 记录存在哪里？
navicat 本身不依赖 postgresql 的系统表或日志来存执行记录——它只在本地缓存，且默认开启自动保存。关键点：这些记录 不上传服务器、不写入数据库、不随 pg_log 走，纯客户端行为。
实操建议：
- 记录默认保存在 Navicat 安装目录下的
History子目录（Windows 路径类似C:\Users\{user}\Documents\Navicat\MySQL\History，注意：即使连的是 PostgreSQL，路径里仍可能显示MySQL，这是 Navicat 旧版命名残留，别被误导） - 文件是加密的二进制格式，不能直接用文本编辑器打开；但 Navicat 自带「历史记录」面板可查看（菜单栏 → 工具 → 历史记录，或快捷键
Ctrl+Shift+H） - 如果清空过 Navicat 缓存、重装过软件、或勾选过「退出时清除历史」，记录就永久丢失，
pg_stat_statements或pg_log都救不回来
PostgreSQL 服务端有没有等效的历史执行记录？
有，但不是“谁什么时候执行了哪条 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'）能记全量，但会产生海量文件，影响性能，且需提前配置——事后无法补录
为什么 Navicat 历史记录突然没了？常见断点在哪
不是 PostgreSQL 出问题，全是 Navicat 客户端侧的隐性开关或路径变更导致。
实操建议：
- 检查 Navicat 设置 → 工具 → 选项 → 环境 → 「退出时清除历史记录」是否被意外勾选（尤其升级后默认可能变更）
- 多用户共用一台电脑时，Navicat 可能读错配置路径：比如当前登录用户是
userA，但 Navicat 启动时读取了userB的History目录（因权限或注册表残留），导致看不到自己的记录 - 使用便携版 Navicat 时，
History目录默认在程序同级，而非用户文档目录；换机器或重装就丢 - macOS 上注意 Spotlight 或 Time Machine 是否排除了
~/Library/Application Support/PremiumSoft/Navicat/，备份失效也会导致丢失
想长期留痕，该靠 Navicat 还是 PostgreSQL？
靠不住任何一个单独组件。真要可靠追溯，必须组合设计。
实操建议：
- 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 默认也不记人。留痕这件事，得从执行动作的设计源头卡住。
