Na vicat 的历史 SQL 记录仅保存在本地客户端的 History 子目录中，为加密二进制格式，不上传服务器、不写入数据库；PostgreSQL 服务端需主动启用 pg_stat_statements 或 log_statement 才能获取统计性或全量执行信息。
Na vicat 的历史 SQL 记录存在哪里？
先说一个核心事实：Na vicat 的历史记录，和 PostgreSQL 服务端本身，基本是“两条平行线”。它不依赖数据库的系统表，也不往服务器日志里写东西——所有的执行记录，都只在你的本地电脑上缓存，而且默认就是自动保存的。关键点就一句话：这些记录不上传服务器、不写入数据库、更不会混在 pg_log 里，完完全全是客户端的独立行为。
具体怎么找？记住这几个实操要点：
- 记录就藏在 Na vicat 安装目录下的
History子目录里。Windows 下的典型路径类似C:\Users\{user}\Documents\Na vicat\MySQL\History。这里有个小坑：即使你连接的是 PostgreSQL，路径里可能依然显示“MySQL”，这是 Na vicat 旧版本命名的历史遗留问题，别被它误导了。 - 文件是加密的二进制格式，直接用文本编辑器打开是乱码。不过，Na vicat 自己提供了查看入口：在菜单栏找到「工具」→「历史记录」，或者直接用快捷键
Ctrl+Shift+H就能调出面板。 - 必须警惕的是，这个本地缓存非常脆弱。如果你清空过 Na vicat 缓存、重装过软件，或者在设置里勾选了「退出时清除历史」，那么这些记录就会永久消失。到时候，就算去查
pg_stat_statements或者翻pg_log，也救不回来。
PostgreSQL 服务端有没有等效的历史执行记录？
有，但别期待过高。服务端提供的主要是统计性、采样式的运行时数据，而不是那种能完整回放“谁在什么时候执行了哪条具体 SQL”的流水账。
想用起来，得主动配置。以下是具体步骤：
- 首先，确认
pg_stat_statements这个扩展是否已经加载。执行SELECT * FROM pg_extension WHERE extname = 'pg_stat_statements';，如果没结果，就需要超级用户权限来运行CREATE EXTENSION pg_stat_statements;。 - 启用后要注意，这个扩展默认只记录聚合指标，比如执行次数、总耗时、平均耗时等等，并不会保存原始 SQL 文本的完整历史。除非你特意将
pg_stat_statements.track参数设为all，并且确保pg_stat_statements.sa ve为on。 - 即便如此，记录下来的 SQL 文本也是被参数化处理过的（比如
WHERE id = $1），具体的绑定值不会保留。而且，这些统计数据会在服务重启，或者手动执行pg_stat_statements_reset()后被清零。 - 另一个方向是启用日志，通过设置
log_statement = 'all'来记录所有语句。这确实能拿到全量信息，但副作用也很明显：会产生海量的日志文件，对性能有影响，并且必须提前配置——事后想补录是绝无可能的。
为什么 Na vicat 历史记录突然没了？常见断点在哪
遇到历史记录消失，问题大概率不在 PostgreSQL，而在于 Na vicat 客户端侧一些容易被忽略的开关或路径变动。
排查时，可以顺着这几个常见“断点”看看：
- 检查 Na vicat 的设置。路径是：工具 → 选项 → 环境 → 找到「退出时清除历史记录」这一项。很多时候，尤其是软件升级后，这个选项的默认状态可能会改变，一不小心就被勾上了。
- 当多用户共用同一台电脑时，可能会出现路径错乱。比如，当前登录用户是
userA，但 Na vicat 启动时却读取了userB的History目录（可能是因为权限问题或注册表残留），导致你完全看不到自己的操作记录。 - 如果你用的是便携版（Portable）Na vicat，那它的
History目录默认就在程序文件同级目录下，而不是标准的用户文档目录。一旦更换机器或重新安装，记录自然就丢了。 - 对于 macOS 用户，还需要留意一下 Spotlight 或 Time Machine 是否排除了 Na vicat 的配置目录（
~/Library/Application Support/PremiumSoft/Na vicat/）。如果备份失效，数据丢失的风险也会大增。
想长期留痕，该靠 Na vicat 还是 PostgreSQL？
坦率地说，想靠任何一个单独组件实现可靠、长期的操作追溯，都不太现实。真想做到这一点，必须进行组合式设计。
具体可以这么操作：
- 将 Na vicat 的历史记录定位为“日常调试辅助”。建议定期手动导出：打开历史记录面板，右键选择「导出到 SQL 文件」，生成一个带时间戳的文件（比如
na vicat_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），最可靠的做法是走正式的变更工单流程，使用脚本执行而非在 GUI 里直接粘贴 SQL。这样一来，执行痕迹自然会落在脚本的版本管理记录和 CI/CD 的日志里，这比任何图形化工具的历史记录都要可靠得多。
说到底，真正的难点从来不是“技术上去哪里找记录”，而是“如何确定谁、在什么业务上下文里、具体改了什么东西”。Na vicat 记不住完整的上下文，PostgreSQL 默认也不会记录操作者。因此，留痕这件事，必须从执行动作的设计源头就考虑周全，把它卡住。
