SQL触发器仅在审计日志、跨表约束校验、单库派生字段同步等强一致且写入路径可控的极少数场景下不可替代；它并非更优，而是别无选择，但易受旁路写入绕过，且存在性能与事务风险。
SQL触发器只在「所有写入路径都可控且必须强一致」的极少数场景下，才比应用代码更可靠——比如审计日志、跨字段约束校验、单库内派生字段自动维护。但它不是“更好”，而是“别无选择”。
审计日志必须走触发器，否则必然漏记
应用层写日志容易被绕过：运维直连数据库执行 UPDATE、ETL工具批量导入、存储过程跳过DAO层……这些路径都不会调用你的Java/Python代码。而触发器只要走标准DML语句（INSERT/UPDATE/DELETE），就一定会触发。
- 必须用
AFTER触发器，确保主表变更已提交再记日志 - 记录
OLD和NEW值时，MySQL用JSON_OBJECT()封装，避免字段增减导致触发器失效 - 不要在触发器里调用外部服务（如HTTP通知），失败会阻塞事务；日志表本身要建好索引，否则高并发下写入拖慢主表
跨表约束校验只能靠触发器兜底
CHECK 约束不能查其他表，外键只支持单字段等值引用。比如“插入订单前检查客户可用余额 ≥ 订单金额”，这个逻辑必须查 customers 表，只能用触发器。
- 必须用
BEFORE INSERT或BEFORE UPDATE，在数据写入前拦截 - 校验失败必须显式报错：
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'insufficient balance'（MySQL）；RAISE EXCEPTION（PostgreSQL）；THROW（SQL Server） - 避免在触发器里做复杂计算或子查询，尤其不要
SELECT ... FROM大表——它会锁住被查行，放大并发冲突
派生字段同步需触发器，但仅限低频小表
像“用户表更新昵称后，自动同步到用户档案表”这类单库内、非实时、低QPS的同步，触发器比应用层双写更省事。但前提是：这张表写入不频繁，且没有批量导入、跨库同步等旁路写入。
- 用
AFTER UPDATE+NEW.id做关联更新，别用SELECT查源表——可能读到未提交脏数据 - 如果目标表有唯一键冲突，MySQL 8.0+ 可用
INSERT ... ON DUPLICATE KEY UPDATE，否则得先DELETE再INSERT - 一旦表日均写入超 1000 次，就要警惕：触发器逻辑会变成性能瓶颈，此时应改用 CDC 或应用层异步消息
真正容易被忽略的点是：触发器永远只对“当前连接执行的那条SQL”生效。DBA手动跑脚本、Flink CDC写入、LOAD DATA INFILE、甚至某些ORM的批量更新（绕过单行触发）——这些都会让触发器彻底失能。你得先确认所有写入入口是否真的只有标准DML，再决定要不要上触发器。
