生产环境不推荐在mysql中使用大量级联触发器，因其将单次dml转为不可控多层事务嵌套，导致锁、日志、死锁风险指数级放大，且问题难以监控复现；级联触发器指跨表链式触发（如orders→users→notification），非递归但隐蔽埋雷，易引发error 1442、死锁闭环及元数据锁争抢，监控压测均难暴露，应改用binlog+cdc、mq、生成列或显式事务替代。
生产环境不推荐在MySQL中使用大量级联触发器，因为它们会把单次DML操作变成不可控的多层事务嵌套，锁、日志、死锁风险全部指数级放大，且问题几乎无法监控和复现。
什么是“级联触发器”？
指一张表的触发器（如 AFTER INSERT ON orders）执行了对另一张表的写入，而那张表又有自己的触发器（如 AFTER UPDATE ON users），进而再触发第三张表……形成链式调用。MySQL 默认禁止递归（max_sp_recursion_depth = 0），但“级联”不是递归——它跨表、跨定义、不报错，只悄悄埋雷。
常见表现包括：
-
ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger这类错误常被误读为“不能更新原表”，实际是级联路径中某处试图回写源头表 - 同一笔订单创建，却在
audit_log、user_stats、notification_queue三张表里各插入一条记录，且顺序不可预测 -
SHOW TRIGGERS查出来十几条，但没人能说清哪条先触发、哪条依赖哪条
级联触发器如何让死锁从“可能”变“必然”？
级联的本质是把多个表的写入逻辑强行塞进一个事务边界，而每张表的锁获取顺序由触发器定义顺序和执行时机决定，完全脱离应用层控制。
典型死锁闭环：
- 事务 A：更新
orders→ 触发器更新users（先锁users.id=123） - 事务 B：更新
users→ 触发器更新orders（先锁orders.id=456） - 此时 A 等 B 释放
orders.id=456，B 等 A 释放users.id=123→Deadlock found when trying to get lock
更麻烦的是：SHOW ENGINE INNODB STATUS 里 trx_query 显示的仍是原始 UPDATE orders，你根本看不到触发器里那句 UPDATE users 是怎么卷进来的。
为什么监控和压测都发现不了级联问题？
因为级联触发器的开销不单独暴露：
-
slow_query_log只记主语句，比如INSERT INTO orders耗时 120ms，但没人知道其中 98ms 花在了三级触发器里的SELECT ... FROM notification_template -
EXPLAIN INSERT INTO orders完全不显示任何触发器内 SQL；必须手动把每条触发器里的SELECT或UPDATE单独拎出来EXPLAIN - 压测脚本用单线程跑
INSERT看起来没问题，一上 32 并发，Innodb_row_lock_waits就飙升——这不是主表慢，是级联路径上某张小表（比如config_cache）被反复加锁
想查某张表是否被级联波及？得人工遍历 INFORMATION_SCHEMA.TRIGGERS，再对每个触发器的 ACTION_STATEMENT 做字符串匹配，没法自动化。
替代方案比“拆级联”更直接有效
级联触发器从来就不是为解耦设计的，强行优化只会让逻辑更晦涩。真实可行的替代路径：
- 审计类操作（如记录变更）→ 改用
ROW格式 binlog + Canal/Flink CDC 解析，完全脱离事务链 - 状态同步（如订单已支付 → 用户积分+1）→ 应用层发 MQ 消息，下游服务消费并重试，失败可告警可补偿
- 字段自动填充（如
updated_at）→ MySQL 8.0+ 用DATETIME AS (NOW()) STORED，零开销、无触发器 - 必须强一致的跨表更新（如库存扣减）→ 改用
SELECT ... FOR UPDATE+ 应用层显式事务，所有锁和超时都在代码里可见、可设、可测
最易被忽略的一点：哪怕你只写了两个触发器，只要它们分别往同一张汇总表（如 daily_summary）写数据，高并发下就会因主键冲突或间隙锁争抢，直接触发 Waiting for table metadata lock ——这不是逻辑问题，是 MySQL 元数据锁机制本身对触发器密集调用的天然排斥。
