触发器在生产环境极易引发性能瓶颈、死锁及故障难定位问题。其禁止事务控制、强制全事务回滚、高频查询拖慢写入、争抢统计表导致死锁、分库分表下失效，且错误隐蔽、监控缺失、排查困难。
生产环境里触发器越复杂，越容易拖垮写入链路、锁死关键表、且问题根本查不到。
触发器内不能提交或回滚事务
触发器运行在主 DML 事务上下文中，COMMIT 和 ROLLBACK 会直接报错 ERROR 1422 或 ERROR 1305。你唯一能做的只有用 SIGNAL SQLSTATE '45000' 抛异常中断整个事务——这意味着：日志写入、状态更新、统计变更等所有关联操作都会一起回滚，而很多业务恰恰需要“主逻辑成功，审计异步落库”。
- MySQL 5.6 及更早版本甚至不支持
SIGNAL，只能靠插入不存在的表这类黑魔法，极不可靠 - 如果触发器调用了含
COMMIT的存储过程，同样触发ERROR 1422，但错误信息完全不提示是哪个过程引发的 - 想“校验失败只回滚触发器部分”？语法上就不允许，ACID 模型在这里被硬性收口
AFTER INSERT 中查配置表 = 每次插入都全表扫描
常见误写：AFTER INSERT 里执行 SELECT COUNT(*) FROM config WHERE key = 'order_timeout'。这种语句本身没问题，但放在触发器里就变成每插入一行都查一次——批量导入 10 万单，就是 10 万次无索引查询。
- 即使
config表只有 10 行，COUNT(*)加WHERE仍可能触发type: ALL（EXPLAIN 显示），尤其当字段类型不一致（如BIGINT对比VARCHAR）时索引完全失效 - 监控上表现为
Created_tmp_disk_tables突增、innodb_row_lock_time_avg翻倍、Threads_running长期卡在高位 - 你看到的慢日志只有
INSERT INTO orders，根本不会出现那条配置查询，定位时得手动翻performance_schema.events_statements_history_long，且SQL_TEXT默认截断
多个触发器争抢同一张统计表 → 死锁高频发生
比如 user_summary 表被 tri_update_order 和 tri_insert_refund 同时更新，两者都按 user_id 主键 UPDATE ... SET total_amount = total_amount + NEW.amount。高并发下极易形成死锁闭环：
- 事务 A 锁了
user_summary行 1001，正等订单表某行；事务 B 锁了订单表那行，正等user_summary行 1001 - 错误日志只显示
Deadlock found when trying to get lock，不标触发器名、不标行号、不标 NEW/OLD 值 - 触发器数量超几十个后，
metadata_lock等待明显上升，连ALTER TABLE都可能被卡住 - 空触发器本身就有 0.1–0.3ms 固定开销；一个带
SELECT ... FOR UPDATE的触发器，5ms 就能让平均锁等待时间翻倍
分库分表或读写分离下触发器直接失效
ShardingSphere、MyCat 等中间件不解析触发器内部 SQL。硬编码表名如 UPDATE order_001 会绕过分片路由规则；触发器只在主库执行，从库回放的是原始 DML —— AFTER INSERT 生成的审计记录在从库上根本不存在。
- 多活架构下双向同步，同一触发器可能在两边重复执行，造成计数翻倍、状态错乱
-
ERROR 1442（"Can't update table in stored function/trigger"）在跨库场景更常见，且错误常被静默吞掉，日志里找不到痕迹 - 想确认某张表有没有触发器？必须手动查
INFORMATION_SCHEMA.TRIGGERS，没法集成进 CI/CD 或监控告警
真正难搞的不是“怎么写对”，而是“出问题时你怎么知道是它干的”。触发器把数据流变成了黑盒，而生产环境最怕的，就是黑盒。
