触发器不能自动转换不同结构的SQL数据源，仅适用于同库同表内轻量级衍生字段处理，跨库、跨结构适配需由ETL或应用层完成。
触发器能自动转换不同结构的SQL数据源吗
不能直接解决多样性问题，触发器只响应单表的增删改操作，它不负责跨库、跨结构的数据适配。如果你指望靠 CREATE TRIGGER 把 MySQL 的宽表、PostgreSQL 的 JSON 字段、SQL Server 的带默认约束列自动对齐成统一 schema，会掉进“逻辑耦合过重”和“事务阻塞”的坑里。
真正可行的做法是：用触发器做轻量级、确定性的本地补全，比如自动生成 updated_at、填充 tenant_id、或把 status_code 映射为 status_text。所有涉及字段映射、类型转换、缺失字段填充的逻辑，必须前置到 ETL 或应用层。
- 触发器适合处理「同库同表内、低延迟、无外部依赖」的衍生字段
- 一旦需要查另一张表、调 API、解析 JSON、或写入其他数据库，就该换方案（比如 CDC + Flink / Debezium）
- MySQL 触发器不支持
SELECT ... INTO赋值给变量以外的复杂查询；PostgreSQL 支持BEFORE行级触发器返回NULL拦截插入，但别在其中做耗时操作
MySQL 和 PostgreSQL 触发器写法差异导致转换失败
同一个转换逻辑，在两个数据库里写法差得远。比如想在插入前把空字符串转为 NULL，MySQL 用 BEFORE INSERT + SET NEW.col = NULL IF(NEW.col = '', NULL, NEW.col)；而 PostgreSQL 必须写函数，再绑定触发器，且 NEW 是记录类型，得用 NEW.col := NULLIF(NEW.col, '')。
更麻烦的是，MySQL 不允许触发器修改其他表，PostgreSQL 允许但会放大锁粒度；SQL Server 的 INSTEAD OF 触发器能拦截视图写入，但 MySQL 没这能力。
- 别试图写“兼容双端”的触发器 SQL —— 语法树根本不同，维护成本爆炸
- 如果必须多库支持，把转换逻辑抽成应用层方法，数据库只留最简触发器（如时间戳更新）
- PostgreSQL 函数里用
RAISE EXCEPTION报错会中断事务；MySQL 用SIGNAL SQLSTATE，但 5.5 以下版本不支持
触发器里调用存储过程做字段转换引发死锁
常见错误：为了复用逻辑，把字段清洗封装成存储过程，再让触发器调用。结果在高并发插入时，多个触发器实例同时执行该过程，争抢同一行或系统表锁，出现 Deadlock found when trying to get lock。
尤其当存储过程中有 UPDATE、INSERT ... SELECT 或显式 LOCK TABLES，问题立刻暴露。这不是代码写得不够优雅，而是违反了触发器的设计边界 —— 它该是轻量、幂等、无副作用的。
- 触发器体内避免任何写操作（除当前行的
NEW修改外） - 禁止在触发器中调用含事务控制（
COMMIT/ROLLBACK）的存储过程 - 如果真要复用清洗逻辑，改用生成式视图（
GENERATED ALWAYS AS）或应用层统一 SDK
为什么用触发器做数据源转换会让监控和排查变困难
因为转换逻辑藏在数据库里，没日志、没 trace ID、不走应用链路。当某条数据的 amount 字段被意外乘以 100，你得先查表结构、再翻触发器定义、再看是否被其他触发器二次修改，最后发现是某个已下线服务还在往旧字段写原始值。
更隐蔽的是时序问题：A 表触发器更新 B 表，B 表又有触发器更新 C 表，三层嵌套后，主事务回滚时部分触发器可能已提交（MySQL 的 AFTER 触发器在事务提交后才执行），造成数据不一致。
- 所有触发器必须加注释，明确写出“影响哪些字段”“依赖哪些条件”“是否可逆”
- 上线前用
SHOW CREATE TRIGGER或\df+ trigger_name核对实际内容，别信 Git 里存的旧版本 - 生产环境禁用递归触发器（MySQL 默认关闭，PostgreSQL 需设
session_replication_role = 'replica'临时绕过）
真正难的不是写对一个触发器，而是确保它在字段变更、索引调整、主从切换、备份恢复这些场景下依然行为可控。多数团队踩坑，都是从“这个小转换放触发器最方便”开始的。
