审计日志写入同一数据库极易引发死锁或循环触发，因主事务未提交前日志已写入，失败回滚导致数据不一致，且日志表若自带触发器会形成隐式递归。
审计日志写入同一数据库
触发器写审计日志到本库的 audit_log 表，极易引发死锁或循环触发。比如用户表更新触发日志插入，而日志表本身也有触发器（哪怕只记录时间戳），就可能形成隐式递归；更糟的是，主事务未提交前日志行已写入，若后续失败回滚，日志却留了下来，数据不一致。
常见错误现象：Deadlock found when trying to get lock、日志条目多于实际变更次数、audit_log 表里出现 NULL 或空值（因触发器中 SYSTEM_USER 或 USER() 在某些连接池场景下不可靠）。
- MySQL 的
TRUNCATE TABLE、LOAD DATA INFILE、从库复制写入，完全不触发任何触发器，审计直接漏掉 - SQL Server 中若日志表启用
change_tracking或自身有触发器，会进一步放大锁等待 - 真正可用的替代：启用
audit_log插件（MySQL）或SQL Server Audit（SQL Server），它们在连接层捕获，覆盖 DDL、登录、所有 SQL 执行状态
复杂报表中间汇总表维护
用触发器实时更新 fact_daily_summary 这类聚合表，不是“准实时”，而是“准失效”。它把业务写入路径拖慢 3–10 倍，且并发稍高就卡死。
典型表现：LCK_M_U 等待超时、Msg 217（嵌套触发器超 32 层）、批量导入后汇总值翻倍（因每行都触发一次 INSERT ... SELECT）。
- 触发器运行在原始事务内，
UPDATE fact_daily_summary和主表更新争同一行锁，而报表表本身就是热点 -
TRUNCATE不触发事件，历史补数时必须手动重算，但触发器逻辑又无法复用 - 正确做法：用定时任务调用存储过程，限定范围如
WHERE uploadTime >= DATEADD(minute, -5, GETDATE())，失败写日志表，支持人工补跑
跨库/跨服务调用
在触发器里调用外部 API、发短信、写 Kafka 或访问另一台 MySQL 实例，等于把网络 I/O 塞进事务里——超时即回滚，但业务可能只想要“尽力而为”。
错误示例：CALL notify_external_service(NEW.order_id) 导致订单插入失败，哪怕库存已扣、消息队列已发。
- MySQL 触发器不支持异步，
SIGNAL报错会中断整个事务，无法降级处理 - SQL Server 中远程查询需启用
RPC和分布式事务，配置复杂且性能极差 - 替代路径：应用层监听 binlog（Debezium）或使用消息队列，把通知逻辑从数据库剥离
字段映射与多源数据适配
指望触发器把 PostgreSQL 的 JSON 字段、MySQL 的宽表、SQL Server 的 computed column 自动对齐成统一 schema，是设计误判。触发器只响应单表变更，不解决结构差异。
问题本质：不同数据库触发器语法树完全不同，NEW.col := NULLIF(NEW.col, '')（PostgreSQL）和 SET NEW.col = NULLIF(NEW.col, '')（MySQL）不能共用，维护成本爆炸。
- MySQL 不允许触发器修改其他表；PostgreSQL 允许但锁粒度扩大；SQL Server 的
INSTEAD OF只适用于视图 - 试图封装字段清洗逻辑到存储过程再被触发器调用，高并发下立刻死锁（多个实例争抢系统表锁）
- 可行边界：仅限同库同表内轻量衍生，如自动生成
updated_at、填充tenant_id、简单枚举映射
真正容易被忽略的一点：触发器无法区分“新增一行”和“修正一行”。比如一条订单记录被反复 UPDATE，触发器每次都会记日志、改汇总、发通知——但业务上这可能只是地址填错了重试三次，不该触发三次库存扣减或三次短信。这种语义模糊性，在生产环境里比性能问题更难排查。
