DBeaver默认不持久化SQL执行记录，仅内存缓存查询历史，关闭即丢失；需启用执行日志或依赖数据库原生日志（如MySQL general_log、PostgreSQL log_statement）实现审计级留存。
默认情况下，DBeaver 不会将 SQL 执行记录持久化到磁盘日志文件中，它只在内存中维护「查询历史」（Query History），关闭软件后即丢失。真要实现可审计、可追溯、满足合规要求的日志留存，必须主动配置外部日志输出或启用数据库原生日志机制。
如何打开并查看 DBeaver 内置的查询历史面板
DBeaver 的 Query History 是唯一开箱即用的执行记录功能，但它不等于审计日志——它不记录用户身份、客户端 IP、执行结果状态码，也不落盘。
- 快捷键：
Alt+Shift+H（Windows/Linux）或Cmd+Shift+H（macOS）直接唤出面板 - 菜单路径：
窗口 > 显示视图 > 其他 > DBeaver > 查询历史 - 面板顶部搜索框支持按
会话 ID、SQL 文本、执行状态过滤，但无法按用户名或时间范围精确筛选 - 历史记录仅限当前连接会话，跨连接不共享；重启 DBeaver 后清空
为什么不能依赖 DBeaver 自身做审计日志
Query History 本质是 UI 层缓存，由 QueryLogViewer 类管理，数据存在内存里，不写磁盘，也不加密。它解决的是“我刚才执行了什么”，不是“谁在什么时候干了什么”。
- 不记录执行者操作系统用户名或数据库登录账号（除非你在连接名里手动标注，但这不可靠）
- 没有失败 SQL 的完整错误堆栈，只显示简略状态如
ERROR或OK - 无法导出为带时间戳的结构化日志文件（如 JSON/CSV），仅支持复制文本行
- 不支持日志轮转、大小限制、自动归档等运维必需能力
真正可行的 SQL 审计日志方案：分两层处理
要满足审计要求（如等保、金融合规），必须组合使用：DBeaver 侧 + 数据库服务端日志。
-
DBeaver 侧辅助记录：启用
SQL Editor > 执行日志（非默认开启）。路径：首选项 > 数据库 > SQL 编辑器 > 执行 > 启用执行日志，勾选后会在控制台输出每次执行的 SQL 和耗时，但仍是内存缓冲，需配合外部工具重定向 stdout -
数据库服务端强制审计：这才是关键。例如 MySQL 开启
general_log并指定general_log_file路径；PostgreSQL 配置log_statement = 'all'+log_directory；Oracle 使用LogMiner解析 redo 日志 -
不要试图用
dbeaver-cli命令行加-output模拟审计：它只输出查询结果，不记录原始 SQL、参数、执行者、时间戳等元信息
最容易被忽略的一点：DBeaver 的「查询历史」和数据库自身的慢日志、通用日志完全隔离。你看到某条 SQL 在 DBeaver 里执行成功，不代表它真的进了数据库日志——如果数据库没开对应日志开关，就等于没发生过。
