触发器无法实现跨库、异构或语义转换的数据字典同步，仅支持同库同结构的DML写入同步；PG的COMMENT等DDL变更需pg_event_trigger捕获，MySQL依赖轮询INFORMATION_SCHEMA，真正可行的是中心化注册或binlog/pg_recvlogical旁路解析。

触发器不能自动同步跨库、异构或带语义转换的数据字典——它只在同库、同结构、字段名/类型/顺序严格一致的前提下，才可能做到“写入即同步”。一旦涉及表注释、列描述、枚举值映射、JSON Schema 转换等元数据操作，触发器就彻底失效。

PostgreSQL 中 COMMENT ON COLUMN 无法被触发器捕获

PostgreSQL 的触发器只响应 DML（INSERT/UPDATE/DELETE），不响应 DDL（如 COMMENT、ALTER TABLE ... RENAME COLUMN）。你改了列注释，触发器根本不知道发生了什么。

• 想监听注释变更？得用 pg_event_trigger + ddl_command_end 事件，但该机制不提供旧值/新值对比，只能靠解析 pg_event_trigger_ddl_commands() 返回的原始命令字符串，极易出错
• COMMENT 本身不走事务日志（WAL），所以 Debezium、Wal2Json 等工具也捕获不到
• 常见错误现象：ERROR: function pg_event_trigger_ddl_commands() does not exist（版本低于 9.3）、或解析出错导致同步服务 crash

MySQL 的 INFORMATION_SCHEMA 不支持触发器绑定

MySQL 没有事件触发器机制，INFORMATION_SCHEMA 是只读视图，不能对其建触发器。你无法让“某张表加了个新字段”这件事自动触发下游字典更新。

• 变通做法只有轮询：定时查 SELECT column_name, column_comment FROM INFORMATION_SCHEMA.COLUMNS WHERE table_name = 'xxx'，再比对哈希或时间戳
• 轮询间隔若设为 1 秒，高并发下会显著增加 INFORMATION_SCHEMA 查询压力；设为 30 秒，又失去“实时性”意义
• 注意 MySQL 8.0+ 的 column_comment 最大长度是 1024 字符，超长会被截断，且不报错

跨库同步数据字典时，触发器会直接失败

即使你硬写一个触发器去连另一个数据库（比如用 mysql_fdw 或链接服务器），只要目标库稍有延迟、权限不足或连接池满，整个主表写入就会被阻塞并报错。

• 典型错误：ERROR 1045 (28000): Access denied for user 'sync_user'@'%' (using password: YES) 或 ERROR 2013 (HY000): Lost connection to MySQL server during query
• SQL Server 链接服务器方案看似可行，但要求两端都开启 MSDTC 分布式事务，而 Azure SQL、RDS 等托管服务默认禁用且不可配
• PostgreSQL 的 dblink 函数在事务中调用失败时，不会回滚远程操作——造成主库成功、从库脏写，元数据彻底不一致

真正能落地的数据字典同步方式只有两种

一种是中心化注册：所有 DDL 变更必须经由统一平台（如 Liquibase + 自定义 extension）执行，并在执行前后主动推送变更事件到 Kafka；另一种是旁路解析：用 pg_recvlogical（PG）或 binlog（MySQL）捕获 DDL 流，再用轻量消费者做字段级 diff 和字典更新。

• 别指望触发器处理 ENUM 值增删、JSONB schema 升级、或 GENERATED COLUMN 定义变更——这些都需要 AST 解析能力，不是 SQL 能搞定的
• 如果业务真需要“改个注释立刻刷新前端字典”，请把字典存成独立 JSON 文件，用 CI/CD 在 DDL 合并后自动生成并推送到对象存储，比数据库内同步更稳更快