为什么CREATE TRIGGER抓不住DDL变更？因为数据库设计之初就没打算让它管这事儿
先说一个核心事实：想用CREATE TRIGGER来自动捕获表结构变更，这条路从一开始就走不通。为什么？因为触发器在MySQL、PostgreSQL这些主流数据库里，天生就是个“数据操作监听器”，它只对INSERT、UPDATE、DELETE这类DML操作有反应。至于ALTER TABLE、DROP COLUMN、ADD INDEX这些改变表结构的DDL命令？触发器完全“听不见”。你试着写一个BEFORE ALTER ON users的触发器，数据库会直接报语法错误——它压根不支持这种玩法。
所以，指望触发器来“自动记录结构变动”，本质上是个伪需求。现实世界里，可行的路径其实非常清晰，主要就两条：
- 放弃实时捕获，转向定期快照比对：比如每天凌晨跑一次
pg_dump --schema-only，或者定时查询information_schema.columns，把结构定义保存下来做对比。 - 将结构变更纳入严格的人工流程：所有
ALTER操作都必须通过SQL变更脚本提交到版本库，然后由专门的部署工具（比如Flyway、Liquibase）来执行和记录。
用 information_schema 手动抓取当前结构快照
这是最轻量、兼容性也最好的方案，适用于MySQL、PostgreSQL（部分视图名不同）、SQL Server等主流数据库。它的核心思路不是“监听事件”，而是“主动查询”系统表。
举个例子，要导出某张表的字段定义快照，在MySQL里可以这么查：
SELECT column_name, data_type, is_nullable, column_default, extra FROM information_schema.columns WHERE table_schema = 'mydb' AND table_name = 'users' ORDER BY ordinal_position;
你可以把这个查询封装成一个脚本，每次上线前手动执行一次，把结果保存成类似users-20240520.json这样的文件。后续的比对工作，交给文本diff工具或者一个简单的Python脚本就能搞定。
不过，这里有几点需要特别注意：
information_schema在PostgreSQL中的对应物是pg_attribute和pg_class等系统表，字段名和查询过滤逻辑会有所不同。- MySQL的
extra字段包含了auto_increment信息，但在PostgreSQL里，你得查pg_get_serial_sequence()函数。 - 只查列信息还不够，索引、约束、外键这些对象，需要额外查询
information_schema.key_column_usage等视图。
Flyway / Liquibase 是事实标准，别自己造轮子
如果你团队的需求是真正可追溯、可回滚、带严格版本号的结构管理，那么Flyway和Liquibase就不是“可选的方案之一”，而是当前业界唯一靠谱的选择。它们根本不依赖数据库的触发器机制，而是通过维护一个已执行脚本的清单（比如V1__init.sql、V2__add_email_index.sql），并在数据库中用一个专门的表（如flyway_schema_history）来记录状态，每次应用启动时进行校验。
Flyway更轻量直接：它只管按顺序执行SQL文件，理念简单，适合由DBA主导或崇尚极简的团队。Liquibase更灵活：它支持用YAML/JSON进行声明式定义，能生成跨数据库兼容的DDL，更适合需要应对多种数据库环境的复杂部署。- 两者都强制“版本化”：每个变更都必须有唯一版本号，这天然就解决了“谁改了啥、什么时候改的”这个核心问题。
- 需要警惕的是：千万别误删那个记录历史的表（比如
flyway_schema_history）。一旦删除，下次工具执行时会认为所有脚本都没跑过，从而导致旧脚本被重复执行，引发Duplicate column之类的错误。
审计 DDL 的唯一可行替代方案：数据库日志 + 解析
当然，存在一些极少数但合理的场景，比如金融行业的合规性强审计，确实需要捕获每一条执行过的ALTER语句。这时候，就得完全绕过触发器，转而依赖数据库自身的日志能力：
- PostgreSQL：开启
log_statement = 'ddl'配置，然后配合pg_log目录的日志轮转，再写一个日志解析脚本（比如用Python提取所有ALTER TABLE.*ADD COLUMN模式的记录）。 - MySQL：可以启用
general_log并设置为表存储（log_output = 'TABLE'），然后直接查询mysql.general_log表。但要注意，这种方式对性能影响较大，通常只用于临时性的审计需求。 - 一个关键限制：日志里记录的只是原始SQL语句，并没有结构变更前后的对比信息。要想还原“到底改了什么”，仍然需要搭配之前提到的快照方法来做diff分析。
话说回来，这种基于日志的方案运维成本高、数据库之间不可移植、也很难集成到现代的CI/CD流程中。因此，除非有合规方面的硬性要求，否则优先选择Flyway那种脚本化的版本管理路径，才是更明智的做法。
