触发器不能替代事务，因其不保证跨表操作原子性；仅适用于innodb表的轻量同步与状态校验，复杂逻辑应由应用层或存储过程替代。
触发器能自动同步关联表，但不能替代事务
MySQL 触发器在 INSERT/UPDATE/DELETE 时自动执行逻辑，适合做轻量级数据同步（比如订单插入后自动更新商品库存），但它本身不开启事务，也不保证跨表操作的原子性。如果触发器里执行的语句失败（例如被 FOREIGN KEY 拒绝或字段类型不匹配），整个原始语句会回滚——这是它“帮上忙”的地方；但若触发器内部用 INSERT INTO other_table 写另一张非事务引擎表（如 MyISAM），那部分操作不会回滚，一致性就断了。
实操建议：
- 只在
InnoDB表上使用触发器，确保引擎支持事务 - 避免在触发器中调用存储过程或发起远程请求，不可控因素太多
- 触发器逻辑尽量简单，比如只更新同一库内的单个字段或计数器，别做复杂计算或连表查询
- 测试时务必用
START TRANSACTION; ... ROLLBACK;包裹主操作，验证触发逻辑是否随主语句一起撤销
BEFORE UPDATE 触发器拦截非法状态变更
当业务要求某些字段只能递增、禁止降级（比如用户等级不能倒退、订单状态只能向后流转），BEFORE UPDATE 是最直接的防线。它在更新真正发生前介入，可通过 SET NEW.status = OLD.status 强制还原，或抛出错误中断操作。
示例：防止订单状态从 'shipped' 误退回到 'confirmed'
DELIMITER $$
CREATE TRIGGER prevent_status_downgrade
BEFORE UPDATE ON orders
FOR EACH ROW
BEGIN
IF OLD.status = 'shipped' AND NEW.status = 'confirmed' THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Status cannot downgrade from shipped';
END IF;
END$$
DELIMITER ;
注意点：
-
SIGNAL只在 MySQL 5.5+ 支持，低版本得靠写入不存在的表来报错（不推荐） - 不要在
BEFORE触发器里读取本表其他行（会报Can't update table 'xxx' in stored function/trigger） - 如果业务允许部分降级（比如从
'delivered'到'shipped'），条件判断要写全，漏掉分支就会绕过校验
触发器更新冗余字段时，必须避开循环调用
常见需求：在 user_profiles 表更新 last_login_time 时，同步刷新 users 表的同名字段。但如果两个表互相建了触发器（A 更新 B → B 的触发器又去更新 A），就会触发 ERROR 1442 (HY000)：“Can't update table in stored function/trigger”。
解决方法只有一个：用单向依赖 + 显式标记
- 只在源头表（如
user_profiles）建触发器，目标表（users）不设反向触发器 - 更新目标表时，加一个临时标记字段（如
updated_by_trigger TINYINT DEFAULT 0），触发器内先设为 1，避免被其他逻辑二次触发 - 更稳妥的做法是放弃触发器，改用应用层统一调用一个存储过程封装这两步更新，并包在事务里
替代方案往往比触发器更可控
触发器像后台幽灵，不调用不出现，但出问题时极难定位：日志里看不到它执行了什么，EXPLAIN 查不到它的开销，监控也抓不住它的慢查询。线上遇到数据不一致，第一反应常是“哪个触发器偷偷改了？”
优先考虑这些替代方式：
- 把校验和同步逻辑提到应用代码里，用同一个事务提交（明确、可测、可打日志）
- 用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO做幂等写入，减少状态冲突 - 对强一致性要求高的场景，用分布式锁 + 版本号控制（如
version字段 +WHERE version = ?） - 真需要异步同步，用 binlog 解析（如 Canal）或消息队列，比触发器更易运维和补偿
触发器不是不能用，而是它的“隐形”特性会让问题延迟暴露——等发现库存对不上了，可能已经积压了几百条脏数据。
