触发器里不能用事务控制，更新失败会直接报错
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+），比触发器更轻量
触发器适合的是“简单、确定、本地、不可绕过”的数据规整动作，一旦逻辑变重，维护成本会快速超过收益。
