MySQL触发器不自动回滚事务，即使抛出异常也只终止当前语句；BEFORE触发器可用于数据校验与修改，AFTER仅适合审计等副作用操作；隐式提交和并发竞争易导致数据不一致。
触发器里没加 ROLLBACK，改了数据却没报错
MySQL 触发器本身不自动回滚事务，哪怕你在 BEFORE INSERT 里抛出异常（比如用 SIGNAL SQLSTATE '45000'），也只终止当前语句，不会撤回已执行的其他 DML。常见错误是以为「触发器报错 = 整个事务失败」，结果 INSERT 失败了，但前面的 UPDATE 已经生效。
实操建议：
- 所有涉及关键数据保护的逻辑，必须显式使用
SIGNAL抛出错误，不能只靠SELECT 1/0这类副作用方式 - 确保触发器运行在支持事务的存储引擎上（如
InnoDB，MyISAM不支持事务，触发器内任何修改都无法回滚） - 如果业务逻辑跨多表、需强一致性，优先考虑把校验和修改逻辑提到应用层或存储过程里统一控制事务边界
BEFORE 和 AFTER 触发器对数据安全的影响差异
BEFORE 触发器能修改即将插入/更新的行（通过 NEW.column），也能阻止操作发生；AFTER 触发器只能读取 NEW 或 OLD，无法改写当前行，更不能阻止主语句执行——这意味着它不适合做准入校验。
典型误用场景：用 AFTER UPDATE 检查金额是否为负，发现后想把字段重置为 0。这已经晚了，主语句已提交，重置操作会额外产生一次写入，还可能引发二次触发。
正确做法：
- 数据合法性检查（如非空、范围、外键关联）一律放在
BEFORE触发器中 -
AFTER触发器只用于审计日志、缓存失效、异步通知等「副作用」操作 - 避免在
AFTER中执行INSERT/UPDATE同一表的操作，容易导致递归触发（除非明确关掉innodb_trx_isolation相关限制或用标志位规避）
触发器中调用存储函数导致隐式提交，破坏事务原子性
MySQL 在触发器里调用含 SELECT ... FOR UPDATE、CREATE TEMPORARY TABLE 或修改数据的存储函数时，会触发隐式提交（implicit commit）。一旦发生，该触发器所在事务就不可回滚，后续 ROLLBACK 无效。
常见现象：主事务里执行一条 INSERT，触发器中调用了自定义函数 log_change()，该函数内部做了 INSERT INTO audit_log，结果主事务报错回滚后，日志表里的记录还在。
规避方法：
- 触发器中禁止调用任何可能引起隐式提交的语句，包括
ALTER、DROP、CREATE、锁表类SELECT - 审计类写入应走
AFTER触发器，并确认目标表也是InnoDB，且函数本身只做简单计算或纯SELECT - 必要时用应用层统一处理日志，或借助 MySQL 8.0+ 的
atomic DDL特性降低风险
高并发下触发器竞争条件（race condition）被忽略
触发器代码看似线程安全，但在并发写入时仍可能出问题。例如：用 BEFORE INSERT 查询当前最大编号再 +1 生成新编号，两个会话同时查到相同值，导致重复编号。
这不是触发器缺陷，而是设计上没考虑隔离级别与并发控制。MySQL 默认 REPEATABLE READ 下，普通 SELECT 不加锁，无法阻止其他事务同时读写同一行。
应对策略：
- 避免在触发器里做「读-改-写」类操作（read-modify-write），这类逻辑应由应用层用
SELECT ... FOR UPDATE显式加锁完成 - 如必须生成唯一序号，优先用
AUTO_INCREMENT、UUID()或数据库序列（MySQL 8.0+ 支持CREATE SEQUENCE） - 若坚持用触发器维护计数器，需配合
GET_LOCK()手动加锁，但会显著降低并发性能，慎用
真正难防的不是语法错误，而是那些看起来跑通了、压测时才暴露的竞态和隐式提交——它们不会报错，但会让数据在某个时间点悄悄偏离预期。
