触发器无法实现跨库、异构或语义转换的数据字典同步，仅支持同库同结构的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值增删、JSONBschema 升级、或GENERATED COLUMN定义变更——这些都需要 AST 解析能力，不是 SQL 能搞定的 - 如果业务真需要“改个注释立刻刷新前端字典”，请把字典存成独立 JSON 文件，用 CI/CD 在 DDL 合并后自动生成并推送到对象存储，比数据库内同步更稳更快
