触发器可做数据清洗，但仅适用于字段级轻量整形；跨表查询、正则替换、JSON解析等复杂操作易阻塞事务，应改用应用层清洗、中间表+定时任务或流式处理。
触发器里做数据清洗，行不行？
行，但得小心——BEFORE INSERT 或 BEFORE UPDATE 触发器确实能拦截原始数据、改写字段再入库，是自动清洗最直接的路径。但它不是万能胶水，尤其当清洗逻辑涉及跨表查、正则替换、JSON 解析或调用外部函数时，容易卡住主事务或拖慢写入。
BEFORE INSERT 触发器中修改 NEW 字段的实操要点
清洗动作必须落在 NEW 上，这是唯一可写的伪记录对象。常见错误是误写成 OLD（只读）、或漏掉 SET 关键字导致赋值不生效。
-
NEW.phone := regexp_replace(NEW.phone, '[^0-9]', '', 'g');—— 清除手机号所有非数字字符（PostgreSQL） -
NEW.email := lower(trim(NEW.email));—— 统一小写并去首尾空格 - 若清洗后发现数据非法（如邮箱格式不对），可用
RAISE EXCEPTION 'invalid email'中断插入，避免脏数据入库 - MySQL 不支持
:=赋值，得用SET NEW.email = LOWER(TRIM(NEW.email));
哪些清洗操作在触发器里会翻车？
触发器本质是事务内同步执行的逻辑，任何阻塞、耗时或不可控的操作都会传染到主 SQL 上。
- 调用
curl或http_get()等网络请求 —— 连接超时直接让整个 INSERT 失败 - 查询大表做
JOIN或子查询（尤其没索引）—— 拖慢写入，还可能引发死锁 - 递归调用自身触发器（比如清洗后又触发另一个触发器更新同一张表）—— PostgreSQL 默认禁用，MySQL 可能爆栈
- 使用
NOW()/CURRENT_TIMESTAMP以外的时间函数（如clock_timestamp()）—— 在语句级触发器中行为不一致
比触发器更稳的数据清洗入口在哪？
如果清洗规则变多、要留痕、要重试或需对接 ETL 工具，触发器就变成技术债。这时候该让出控制权：
- 应用层清洗：在 ORM 或 DAO 层统一处理，日志好打、逻辑好测、异常好捕获
- 中间表 + 定时任务：先
INSERT INTO raw_table，再由后台脚本跑清洗逻辑落clean_table，失败可人工干预 - 物化视图或实时物化（如 PostgreSQL 15+ 的
REFRESH MATERIALIZED VIEW CONCURRENTLY）—— 适合清洗后只读场景 - 流式清洗（如 Debezium + Flink）—— 当清洗依赖外部维度表或需窗口计算时，这才是合理边界
触发器适合“字段级轻量整形”，比如去空格、转大小写、补默认值；一旦出现条件分支嵌套、跨源映射、或需要审计清洗前后的差异，它就不再是首选方案了。
