MySQL触发器不应使用多层IF-ELSE嵌套实现复杂逻辑，而应将校验、查询、状态转换等封装进存储过程，触发器仅负责调用；避免COUNT(*)改用EXISTS+索引；精准检测字段变更优于嵌套判断。
MySQL 触发器不适合用多层
嵌套实现复杂业务逻辑——它会迅速失控，且多数你以为“必须嵌套”的场景，其实有更稳、更快、更可维护的替代方案。
触发器里写多层 IF-ELSE 的典型失败表现
常见错误现象：
（修改正在变更的表）、
（标量子查询非法）、单条
耗时从几毫秒飙到几百毫秒。这些不是代码写得不够“精巧”，而是结构本身越界了。
BEFORE INSERT 中连写三层
，中间还夹着
和
—— 这已超出触发器职责边界
想靠
判断多个条件组合，结果 MySQL 直接报错：不允许在条件表达式中用子查询
嵌套过深导致调试困难：改一行逻辑要反复删触发器、重装、清缓存，而问题可能出在某层
被误读或索引没命中
真正该用存储过程封装，而不是在触发器里硬塞逻辑
把判断分支、多表查、状态转换等全部抽到存储过程中，触发器只做“调用”和“兜底”。这是唯一能兼顾可读性与事务安全的做法。
封装完整校验链，包括库存扣减、信用检查、优惠叠加规则
触发器里只留一句：
存储过程声明为
，不带
/
，确保能被触发器安全调用
所有复杂分支都在存储过程中单元测试，触发器只需验证“是否成功调用”
跨状态、多条件校验必须用 EXISTS + 索引，别碰 COUNT(*)
哪怕你只写一层
，只要里面是
，就已在生产环境埋雷。
错误写法：
正确写法：
必须确认
有联合索引，否则
也慢
如果涉及三张表以上 JOIN 校验，直接放弃触发器方案——这种逻辑本就不该在数据库层实时跑
BEFORE UPDATE 中用 OLD/NEW 做精准变更检测，比嵌套更高效
很多所谓“复杂逻辑”，本质只是“字段变了才执行后续动作”。这时用
比任何嵌套都干净。
例如只在
从
变为
时发通知：
注意：JSON 字段或生成列的比较要用
或显式类型转换，直接
可能静默失效
避免对
赋值（如
），MySQL 会忽略且不报错——这是最难复现的坑
复杂点从来不在语法嵌套层数，而在逻辑是否该由数据库实时承担。一个触发器超过 20 行、含 2 个以上
、或依赖外部表状态，基本就该砍掉重设计了。
IF-ELSEERROR 1442ERROR 1356INSERTIF NEW.status = 'A' THEN ... ELSEIF NEW.type = 'B' THEN ...SELECT COUNT(*)UPDATEIF (SELECT ...)OLDCREATE PROCEDURE CheckAndApplyRule(IN p_order_id INT, IN p_action VARCHAR(20))CALL CheckAndApplyRule(NEW.order_id, 'INSERT');READS SQL DATACOMMITROLLBACKIFSELECT COUNT(*) > 0IF (SELECT COUNT(*) FROM contracts WHERE user_id = NEW.user_id AND status = 'active') > 0 THEN ...IF EXISTS (SELECT 1 FROM contracts WHERE user_id = NEW.user_id AND status = 'active') THEN ...contracts(user_id, status)EXISTSIF OLD.field != NEW.fieldstatus'pending''confirmed'IF OLD.status = 'pending' AND NEW.status = 'confirmed' THEN INSERT INTO notifications ...JSON_EXTRACT!=OLDSET OLD.flag = 1SELECT