DBeaver 不具备数据变更审计能力，仅提供本地会话级SQL执行记录；追溯“谁、何时、改了什么”必须依赖MySQL服务端的binlog、通用日志或审计插件，或通过触发器、应用层埋点实现。
DBeaver 本身不记录谁改过数据，它只是执行 SQL 的客户端，不是审计系统。 所有修改操作都由 MySQL 服务端完成，DBeaver 不保存用户身份、会话上下文或变更前后的值——它连“哪个窗口执行了哪条语句”都只在当前会话内存里暂存，关掉就丢。真要追溯“谁、什么时候、改了什么”，必须依赖 MySQL 服务端的日志能力，而不是 DBeaver 界面点点点。
MySQL 没开审计日志，DBeaver 就啥也查不到
默认安装的 MySQL 完全不记录谁执行了 UPDATE 或 DELETE。你打开 DBeaver 的“查询日志”面板看到的，只是当前连接中你本人执行过的语句列表，字段只有时间、SQL 文本、耗时、状态，没有用户名、主机 IP、会话 ID（除非手动查 SHOW PROCESSLIST）。即使你开了“历史记录”（Ctrl+H），那也只是本地缓存的 SQL 文本，不带执行者信息。
- 确认是否启用二进制日志：
SHOW VARIABLES LIKE 'log_bin';—— 返回OFF就说明没开，ON也不代表能直接看出“谁改的”，只说明有变更事件流 - 检查是否启用通用查询日志（
general_log）：SHOW VARIABLES LIKE 'general_log';—— 开启后会记所有语句和连接来源，但性能损耗大，生产环境极少长期开启 - MySQL 8.0+ 的企业版才原生支持
audit_log插件，社区版需用第三方方案（如 Percona Server 的 audit log）
用 DBeaver 查当前会话的执行痕迹（仅限你自己）
如果你只想确认“我刚刚是不是在 DBeaver 里执行过某条更新”，可以快速回溯：
- 在 SQL 编辑器中按
Ctrl+H（Windows/Linux）或Cmd+H（macOS）打开“历史记录”面板，里面是当前连接生命周期内你执行过的所有 SQL - 点击工具栏的“查询日志”按钮（? 图标），或菜单
窗口 > 显示视图 > 查询日志，这里能看到更细粒度的时间戳、执行时长、结果行数 - 在“查询日志”面板顶部搜索框输入关键词，比如
UPDATE users或SET status=1，实时筛选 - 右键某条记录 → “在新编辑器中打开”，可复核完整语句；但注意：它不会显示该语句执行时的参数值或影响行数（除非你当时勾选了“显示影响行数”）
真正能追溯“谁改的”，得靠数据库层设计
如果业务上必须审计数据变更，别指望 DBeaver 提供功能，而是要在 MySQL 侧做三件事：
- 建审计表 + 触发器：例如为
orders表建orders_audit，在AFTER UPDATE触发器里插入USER()、NOW()、OLD.*和NEW.*—— 这样每条变更都带执行者和上下文 - 用
binlog解析：通过mysqlbinlog工具解析二进制日志，配合--base64-output=DECODE-ROWS -v可看到行级变更，但需要知道具体时间范围和 binlog 文件名，且不直接显示用户名（需结合host和连接时间反推） - 应用层埋点：在业务代码里统一调用封装好的更新接口，强制写入操作人 ID 到扩展字段或独立日志表，比数据库触发器更可控、更易关联业务上下文
最容易被忽略的一点：DBeaver 的“查询日志”和“历史记录”默认只保留当前会话，关闭连接即清空；即使你在 首选项 > 数据库 > SQL 编辑器 > 查询历史 里勾选了“保存历史”，它也只存 SQL 文本，不存执行者、不存参数、不存结果集快照——这些都不是它的职责范围。
