MySQL不记录表创建者，INFORMATION_SCHEMA.TABLES无CREATE_USER字段，DBeaver无法显示真实创建人；需依赖审计日志、应用日志或Git历史追溯。
MySQL 本身不记录表的创建者（CREATE_USER），DBeaver 作为客户端也无法凭空显示“谁建的这张表”。你看到的“创建者”信息，实际取决于底层数据库是否存储并暴露了该元数据——目前只有部分数据库（如 Oracle、SQL Server）原生支持，而 MySQL 默认不保存、也不在标准 INFORMATION_SCHEMA.TABLES 中提供该字段。
MySQL 表没有 CREATE_USER 字段怎么办
MySQL 的 INFORMATION_SCHEMA.TABLES 表里只有 CREATE_TIME 和 UPDATE_TIME，没有 CREATE_USER。哪怕你是 root 登录建的表，DBeaver 也查不到“创建人”是谁。
- 执行
SELECT TABLE_NAME, CREATE_TIME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'users';只能确认时间，不能确认人 - MySQL 8.0+ 引入了
mysql.innodb_table_stats和审计日志（需提前开启），但这些不是默认启用，且不直接关联到建表语句的执行用户 - 如果你用的是 MySQL 5.7 或更早版本，基本可以确定：这个信息根本不存在于库内
DBeaver 里右键“查看表属性”为什么没显示创建者
因为 DBeaver 的“表属性”面板读取的是 JDBC 驱动返回的元数据，而 MySQL Connector/J 对 getCreateUser() 这类方法返回 null 或空字符串——它不实现该接口。这不是 DBeaver 的 bug，是驱动和 MySQL 协议层的限制。
- 你点开任意一张表 → 右键 → “编辑表”或“查看属性”，看到的“Owner”字段为空或显示为当前登录用户，那是 DBeaver 的 fallback 显示逻辑，并非真实记录
- 某些旧版 DBeaver（≤21.x）甚至会把连接用户名硬写进 Owner 栏，造成误导
- 验证方式：换一个用户（比如
app_user）连上去看同一张表，Owner 栏可能还是显示root——说明它没实时查库，只是缓存/猜测
真要追溯建表人，只能靠外部手段
如果审计合规或排查需要知道“谁在什么时候建了这张表”，必须依赖数据库外部机制，而不是指望 DBeaver 点两下就出来。
- 开启 MySQL 普通查询日志（
general_log=ON）：会记录所有语句及执行用户，但 I/O 开销大，仅限临时排障；日志路径需在配置中指定，DBeaver 无法直接读取 - 启用 MySQL 企业版审计插件（
audit_log）或社区替代方案（如 MariaDB 的server_audit）：可过滤出CREATE TABLE事件及对应user@host - 应用层日志：如果表是通过 ORM（如 Django migrations、Flyway、Liquibase）创建的，查对应工具的执行记录和 CI/CD 流水线日志更可靠
- Git 历史：建表 SQL 如果纳入版本控制（如
sql/migrations/001_create_users.sql），git blame就是最准的“创建者”来源
真正难的不是“怎么在 DBeaver 里点出来”，而是 MySQL 从设计上就没打算存这个字段。别在 UI 上浪费时间找不存在的按钮，优先检查日志开关或代码仓库——那才是唯一可信的源头。
