DBeaver 不自动记录 MySQL 表结构变更历史，因其不解析 DDL 语义、不保存元数据快照；需通过 Git 管理 SQL 脚本并配合审计流程实现可追溯变更。
DBeaver 本身不自动记录 MySQL 表结构变更历史，它不解析或归档 ALTER TABLE 等 DDL 语句的执行效果，也不保存元数据快照 —— 这是数据库层面的功能缺失，不是客户端能绕过的。
为什么 SQL 历史里看不到表结构变化的“前后对比”
DBeaver 的 SQL History（快捷键 Alt+Shift+H）和 Query Log（快捷键 Alt+Shift+Q）只记录你执行过的原始语句文本、时间、连接信息和执行结果，但：
- 不会主动解析
CREATE TABLE或ALTER TABLE的语义，更不会抓取执行前后的INFORMATION_SCHEMA.COLUMNS差异 - 如果语句执行失败（比如语法错、权限不足），它仍会记录该语句，但不会标记“未生效”，容易误判为已变更
- 多人共用同一连接时，历史混杂，无法绑定到具体用户或会话上下文
- 默认保留策略是“最近 30 天”，老记录会被自动清理，且不备份到磁盘外
想追踪结构变更，必须自己建审计表 + 触发器（MySQL 侧）
这是目前最可控、可审计、与 DBeaver 配合最直接的方式。核心思路：让数据库自己记下谁、什么时候、改了哪张表的什么字段。
- 先创建审计表：
CREATE TABLE schema_audit_log (id BIGINT AUTO_INCREMENT PRIMARY KEY, event_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, user_host VARCHAR(100), db_name VARCHAR(64), table_name VARCHAR(64), event_type VARCHAR(20), sql_text TEXT) - 再在
mysql系统库中创建触发器（需 SUPER 权限）：CREATE TRIGGER audit_ddl AFTER INSERT ON mysql.general_log FOR EACH ROW ...—— 但注意：MySQL 8.0+ 默认关闭general_log，且该日志不区分 DDL/DML，开销大，不推荐 - 更稳妥做法：在业务库中对关键表手动加
BEFORE ALTER类触发器（MySQL 不支持 DDL 触发器，所以实际只能靠约定 + 审计流程） - 因此，**真正可行的方案是：禁用直接 DDL，全部走带版本号的 SQL 脚本 + Git 管理**，DBeaver 仅作为执行终端
用 DBeaver + Git 实现结构变更可追溯（推荐工作流）
把 DBeaver 当作“脚本执行器”，而非“变更源头”。所有结构修改必须写成独立 SQL 文件，纳入 Git 版本控制：
- 新建文件夹
/migrations/，按命名规范存放：V20261103_001_add_user_status_column.sql - 在 DBeaver 中右键数据库 → “工具” → “执行脚本”，选中该文件执行
- 执行前务必勾选“显示执行计划”和“确认每个语句”，避免误批量执行
- 每次执行后，立即提交 Git：
git add migrations/V*.sql && git commit -m "add user.status column for KYC flow" - 配合 DBeaver 的
Query Log面板筛选出该次执行的会话 ID，可反向关联 Git 提交哈希（需人工备注）
容易被忽略的关键点
DDL 变更不可逆，而 DBeaver 不提供回滚预览；Query Log 中的 session_id 是连接级标识，重启 DBeaver 或重连即失效；如果你依赖 INFORMATION_SCHEMA 手动比对结构，记得加上 WHERE TABLE_SCHEMA = 'your_db'，否则可能跨库污染结果；Git 提交信息里建议固定包含数据库名、环境标签（如 [prod]）、影响行数估算（如 +1 col, ~2M rows）—— 这些才是线上事故复盘时真正有用的信息。
