DDL触发器仅支持SQL Server，用于审计日志但无法回滚或还原结构；MySQL无原生DDL触发器，PostgreSQL的event_trigger仅可监听不可拦截；结构变更必须依赖外部备份、版本化脚本或主动快照。
CREATE TRIGGER 不能捕获 DDL（如 ALTER TABLE、DROP COLUMN），MySQL 和 PostgreSQL 的普通 DML 触发器只响应 INSERT/UPDATE/DELETE，对结构变更完全无感。SQL Server 的 DDL TRIGGER 虽支持，但仅限该平台，且无法跨库回滚或还原结构——DDL 一旦执行，就不可逆。
DDL TRIGGER 在 SQL Server 中能做什么、不能做什么
- SQL Server 确实提供
DDL TRIGGER，可监听ALTER_TABLE、CREATE_INDEX等事件 - 它能记录操作时间、执行人（
ORIGINAL_LOGIN()）、T-SQL 文本（EVENTDATA()）到日志表 - 但它不参与事务：即使触发器里
RAISERROR报错，ALTER TABLE已生效，无法回滚 - 它不保存旧结构快照：你只能看到“谁在什么时间执行了什么语句”，看不到改之前字段类型、约束、索引定义长什么样
常见错误现象：
- 误删主键后想靠触发器日志“还原结构”，结果发现日志里只有
ALTER TABLE orders DROP CONSTRAINT PK_orders，没存原约束定义 - 把
DDL TRIGGER当成 Git，以为能git checkout v2.1恢复表结构，实际它连SHOW CREATE TABLE快照都不生成
实操建议：
- 仅用作审计留痕，不用于恢复；恢复必须依赖外部备份或
mysqldump --no-data/pg_dump -s生成的 DDL 文件 - 若需自动抓取结构快照，应由运维脚本定时调用
SHOW CREATE TABLE orders并存入元数据表，而非依赖触发器
MySQL 和 PostgreSQL 根本没有 DDL TRIGGER，怎么办
MySQL 8.0+ 无原生 DDL 触发器；PostgreSQL 的 event_trigger 可监听 DDL，但它是独立对象，不绑定到具体表，且函数返回值不能阻止操作（pg_event_trigger_ddl_commands() 只读）。
这意味着：
- 你无法在 MySQL 中写一个
BEFORE ALTER TABLE来拦截或校验字段长度变更 - PostgreSQL 的
event_trigger可以记录ALTER COLUMN TYPE，但不能像行级触发器那样访问OLD/NEW结构差异
实操建议：
- 所有 DDL 必须走 CI/CD 流水线或 DBA 审批流程，配合 Liquibase / Flyway 等工具管理版本化 SQL 脚本
- 在脚本执行前，自动调用
mysqldump --no-data db_name table_name > schema_v20260412.sql存档 - 不要试图用触发器“兜底”结构变更——它不是设计来干这个的
为什么有人坚持要用触发器管 DDL？踩坑典型场景
- 把
AFTER UPDATE触发器逻辑套用到 DDL 上，误以为“只要写个触发器就能自动备份结构” - 在应用层执行
ALTER TABLE后，发现历史表里没新增记录，才意识到触发器根本没触发 - 用
information_schema.COLUMNS定时轮询对比字段数量变化，当成“自动检测”，结果漏掉默认值、注释、字符集等细微变更
关键区别必须认清：
- 行级触发器作用于数据行生命周期（
NEW/OLD可见） - DDL 变更是数据库对象元数据的突变，不经过事务引擎的数据路径，也不产生“行”概念
真正可落地的方案只有两个：
- 应用层/运维侧主动快照：每次 DDL 前手动或脚本导出
SHOW CREATE TABLE - 数据库外监控：用 pt-online-schema-change 的钩子、或解析 binlog / wal 日志提取 DDL 语句（需额外组件）
结构版本化不是“加个触发器就能自动跑起来”的事。它本质是流程问题，不是技术问题。把希望押在触发器上，等于让门卫去管大楼图纸修订——他能看到谁进了楼、几点进的，但不会帮你存一份旧版施工图。
