MySQL触发器不支持事务控制，更新失败直接报错；BEFORE UPDATE可修改NEW值实现数据校验与修正，AFTER触发器适用于审计日志；复杂逻辑应优先考虑应用层处理或binlog解析。
触发器里不能用事务控制，更新失败会直接报错
MySQL 触发器本身不支持 BEGIN...COMMIT 或 ROLLBACK，也不能显式开启事务。如果在 BEFORE UPDATE 触发器里执行非法操作（比如向不存在的表插入、违反 NOT NULL 约束），整个 UPDATE 语句会立即中断并抛出错误，原记录不会被修改。
常见踩坑点：
-
NEW字段赋值时类型不匹配（如把字符串赋给INT列），触发器静默失败或报Truncated incorrect DOUBLE value - 在
AFTER UPDATE里再更新本表，可能引发“Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger” - 触发器中调用存储函数，而该函数又含写操作，同样会触犯 MySQL 的限制
BEFORE UPDATE 是唯一能真正“拦截并修正”数据的位置
只有 BEFORE UPDATE 允许你修改 NEW 的值，从而影响最终写入的数据。这是实现业务校验、默认值填充、字段联动更新的核心位置。
典型用法示例：
CREATE TRIGGER tr_user_updated_at
BEFORE UPDATE ON users
FOR EACH ROW
SET NEW.updated_at = NOW(),
NEW.status = IF(NEW.email IS NULL, 'inactive', NEW.status);
注意：
-
NEW表示即将写入的新行，OLD表示原值，仅在UPDATE和DELETE中可用 - 不能在
BEFORE UPDATE中读取本表其他行（除非用子查询且满足只读限制），否则可能报错 - 如果逻辑复杂，建议把校验逻辑抽成存储函数，但函数内仍不能修改当前表
审计日志类场景优先用 AFTER INSERT/UPDATE，但要避开主表更新
记录操作日志、同步变更到历史表这类需求，必须用 AFTER 触发器，因为此时原语句已成功提交，数据稳定。
安全写法要点：
- 日志表名别和主表太像（比如
users_log而非users_history），避免误操作 - 日志字段尽量用
TEXT或JSON存原始变更（如JSON_OBJECT('old', JSON_OBJECT('name', OLD.name), 'new', JSON_OBJECT('name', NEW.name))） - 避免在触发器里做耗时操作（如 HTTP 请求、大表 JOIN），会拖慢主 DML 性能
替代方案更可控：应用层钩子 or binlog 解析
真正需要强一致性或复杂流程（比如更新用户状态同时发消息、调外部 API、跨库同步），触发器不是首选。它难调试、难测试、易被绕过（如批量导入跳过触发器）。
更稳的做法：
- ORM 层统一封装
save()方法，在其中嵌入校验与副作用逻辑 - 用
mysqlbinlog或 Debezium 监听 binlog，异步消费变更事件 - 关键业务字段加
CHECK约束或生成列（MySQL 8.0+），比触发器更轻量
触发器适合的是“简单、确定、本地、不可绕过”的数据规整动作，一旦逻辑变重，维护成本会快速超过收益。
