触发器不独立事务，与触发sql共享事务上下文，执行dml会延长锁持有时间、扩大锁范围，并加剧mvcc开销。
触发器执行时会隐式延长事务生命周期
触发器不是独立事务，它和触发它的那条SQL共享同一个事务上下文。只要触发器里有DML操作（比如UPDATE、INSERT），就会继续持有原事务已获取的锁，并可能新增行锁或间隙锁。这意味着：原本一条UPDATE语句只锁1行，加上触发器后可能变成锁3张表的多行——锁范围扩大、持有时间拉长，其他事务一碰就等。
常见错误现象：SHOW ENGINE INNODB STATUS里看到大量LOCK WAIT状态，且trx_query显示的是主SQL，但实际阻塞源是触发器里的语句；监控发现innodb_row_lock_time_avg陡增，而QPS没明显变化。
- 触发器内避免
SELECT ... FOR UPDATE或UPDATE非主键字段（易触发间隙锁） - 不要在触发器里调用存储过程或外部函数，它们可能隐式开启子事务或加锁
- 如果触发器逻辑复杂（如更新汇总表+写日志表），考虑改用应用层异步任务替代
批量DML触发大量触发器调用导致锁堆积
MySQL触发器是基于行的，INSERT INTO t VALUES (1),(2),(3)会触发3次触发器执行。当批量插入/更新500行时，等于串行执行500次触发器逻辑——不仅CPU和IO翻倍，更致命的是：每一轮都尝试获取新锁，极易和并发事务形成锁序逆序。
使用场景：订单批量导入、日志归档同步、ETL数据清洗。这类操作本就容易锁表，再叠加触发器，innodb_lock_wait_timeout超时就成了常态。
- 确认是否真需要触发器：比如“插入订单后更新用户最近下单时间”，完全可用
ON DUPLICATE KEY UPDATE或应用层单条UPDATE合并 - 若必须用，确保触发器内所有DML都走主键或唯一索引，避免全表扫描引发的表级锁升级
- 对大批次操作，先
SET autocommit = 0，手动控制事务边界，别让每个触发器都自动提交
触发器与长事务叠加放大MVCC开销
触发器本身不产生undo log，但它延长了外层事务的存活时间。一个执行3秒的触发器，会让整个事务的trx_started时间推迟3秒——这期间所有被修改行的历史版本都得保留在undo log里，Buffer Pool里缓存的旧版本页无法被清理，查询时遍历版本链的成本指数上升。
性能影响比想象中更隐蔽：你可能只看到慢查询日志里某条SELECT耗时2s，却不知道它其实在遍历87个MVCC版本，而根源是某个凌晨跑的定时任务触发器没及时提交。
- 用
SELECT * FROM information_schema.INNODB_TRX WHERE trx_started 定期扫出长事务 - 在触发器开头加
IF NOT EXISTS(SELECT 1 FROM information_schema.INNODB_TRX WHERE trx_id = CONNECTION_ID()) THEN ...做轻量级规避（仅限调试） - 关键业务表禁用触发器，改用应用层统一hook点（如MyBatis Interceptor）做后置处理
InnoDB下触发器的原子性陷阱会掩盖死锁根因
在InnoDB表上，触发器操作和主SQL是原子的，但报错信息不会明确区分失败点。比如INSERT触发器里有一条UPDATE summary SET total = total + 1，若该语句因锁等待超时失败，MySQL只抛Deadlock found when trying to get lock，你查trx_query看到的却是原始INSERT语句，根本意识不到问题出在触发器内部。
这种“黑盒感”让死锁分析成本翻倍：你得把触发器代码展开，模拟每一步加锁顺序，再和并发事务对比——而实际线上环境往往连触发器定义都查不到（被运维禁用SHOW CREATE TRIGGER权限）。
- 所有触发器必须带
COMMENT说明锁行为，例如COMMENT 'locks summary table by user_id' - 禁止在触发器里做跨库、跨表关联更新，这类操作锁范围不可控
- 上线前用
pt-deadlock-logger持续采集死锁日志，重点过滤含TRIGGER关键词的堆栈
触发器真正的危险不在它做了什么，而在它让事务边界变得模糊——你永远不知道哪一行数据正被哪个看不见的触发器锁着，又或者哪个看似简单的INSERT正在后台悄悄拖垮整个数据库的MVCC清理线程。
