触发器是否在事务内部执行
是的，MySQL 中的触发器默认运行在当前语句所属的事务上下文中。也就是说，
INSERT、
UPDATE或
DELETE触发的触发器，其所有操作（包括对其他表的修改）都和原语句共享同一个事务 ID，一起提交或一起回滚。
这意味着：如果触发器里执行了
INSERT INTO log_table，但后续主语句因约束失败而回滚，那这条日志也不会留下——除非你显式用了
CREATE DEFINER = ... SQL SECURITY DEFINER+ 自定义存储过程绕过事务（不推荐）。 触发器无法开启新事务（MySQL 不允许在触发器中使用
BEGIN...END事务控制语句）
START TRANSACTION、
COMMIT、
ROLLBACK在触发器内会直接报错：
ERROR 1305 (42000): SAVEPOINT does not exist或类似提示 若想“保底写日志”，得用外部服务（如消息队列）或 MySQL 8.0+ 的
WRITE_ONLY表 + 异步落盘方案，而非依赖触发器本身
并发下触发器可能引发的锁等待与死锁
触发器执行时会按需加锁，和普通 DML 行为一致。例如一个
BEFORE UPDATE触发器去查并更新另一张配置表
config，那它就会持有
config上的行锁或表锁（取决于隔离级别和查询条件），进而阻塞其他并发事务。
典型死锁场景：
事务 A：UPDATE orders SET status='shipped' WHERE id=100 → 触发器读取 config 表 → 锁住 config.id=1<br>事务 B：UPDATE config SET value='x' WHERE id=1 → 同时触发器更新 orders 日志表 → 锁住 orders.id=100
此时 A 等 B 释放
config.id=1，B 等 A 释放
orders.id=100，死锁成立。 避免在触发器中访问高频更新的辅助表；优先用只读缓存或应用层预加载 确保触发器内所有 DML 操作的表访问顺序一致（比如总是先查
user再查
log），降低死锁概率 监控
SHOW ENGINE INNODB STATUS中的
LATEST DETECTED DEADLOCK区域，确认是否由触发器引起
不同 MySQL 版本对触发器事务行为的影响
MySQL 5.7 和 8.0 在触发器事务语义上基本一致，但有两处关键差异：
MySQL 8.0 支持原子 DDL，所以CREATE TRIGGER本身是原子的；5.7 下若创建触发器中途失败，可能残留半成品元数据（极少见但存在） MySQL 8.0 默认开启
binlog_format = ROW，触发器产生的变更会被完整记录到 binlog；而 5.7 若设为
MIXED或
STATEMENT，某些触发器逻辑可能无法正确复制（例如含
NOW()、
UUID()的语句） MySQL 8.0.13+ 新增
trigger_order属性（
FOLLOWS/
PRECEDES），允许多触发器按序执行，但它们仍共属同一事务，不改变事务边界
替代触发器实现事务一致性更可控的方式
如果你发现触发器越来越难维护、锁冲突频繁、或需要跨库/跨服务协同，说明它已经超出适用边界。更可控的做法是把逻辑上收：
用存储过程封装主操作 + 关联变更，统一控制事务边界和错误处理（例如CALL process_order(100)内部做
UPDATE orders+
INSERT INTO history+
UPDATE inventory） 应用层用本地事务（如 Spring
@Transactional）协调多个 DAO 调用，比数据库层触发器更容易测试、回滚粒度更细 对审计类需求，改用 MySQL 8.0 的
Audit Log Plugin或开启
general_log（注意性能开销），而不是靠触发器写日志表
触发器适合简单、确定、低频、单库内的副作用，比如自动生成 UUID、校验字段格式、同步更新计数器。一旦涉及多表强一致性或高并发写入，它的隐式行为就容易成为瓶颈。
