MySQL触发器中父级状态校验必须在BEFORE UPDATE中用SELECT INTO读取，不可用子查询；AFTER中无法回滚且易触发ERROR 1442；需防NULL、索引缺失、状态值不一致及并发快照问题。
BEFORE UPDATE 触发器里怎么读取父级状态
必须用 SELECT ... INTO 从父表查状态，不能直接 JOIN 或子查询作条件——MySQL 触发器中不允许在 IF 表达式里写标量子查询。常见错误是写 IF (SELECT status FROM parent WHERE id = NEW.parent_id) != 'active' THEN ...，这会报 ERROR 1356。
实操建议：
- 先声明变量：
DECLARE parent_status VARCHAR(20); - 再查赋值：
SELECT status INTO parent_status FROM parent_table WHERE id = NEW.parent_id; - 加
IF parent_status IS NULL THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '父记录不存在'; END IF;防空指针 - 确保
parent_table.id有索引，否则每次 UPDATE 都全表扫
为什么不能在 AFTER UPDATE 里校验父级状态
AFTER 触发器运行时，当前行已更新完成，父级状态校验失败也无法回滚本次修改。更危险的是：如果校验逻辑本身要改父表（比如递增父表计数器），就会触发 MySQL 经典报错 ERROR 1442: Can't update table 'parent_table' in stored function/trigger。
实操建议：
- 所有状态拦截必须放在
BEFORE UPDATE中，靠SIGNAL中断执行 - 别试图在 AFTER 里“补救”，比如发现父状态不对就 UPDATE 回去——这既不原子，也违反业务语义
- 若真需联动更新，应由应用层发起两阶段操作，或用存储过程封装（仍需避开同表更新）
跨表状态校验的性能和事务风险
触发器里查父表看似简单，但每行 UPDATE 都触发一次 SELECT，在批量更新（如 UPDATE child SET x=1 WHERE parent_id IN (1,2,3)）时会放大 N 倍 I/O。更隐蔽的问题是：父表被其他事务正在修改，而触发器读到的是 READ COMMITTED 级别的快照，可能校验通过后父状态立刻变更。
实操建议：
- 避免在触发器里做
SELECT ... FOR UPDATE—— MySQL 不允许在触发器中加写锁 - 如强依赖父状态一致性，应用层应在同一事务中先
SELECT parent FOR UPDATE，再更新子表 - 高频场景下，把父状态冗余到子表（如
parent_status字段），用触发器维护，校验时直接读NEW.parent_status - 不要在触发器里调用含事务逻辑的函数，否则可能隐式破坏外层事务边界
常见业务流程误判点：status 字段值 vs 业务语义
直接比对 OLD.status != NEW.status 或 NEW.parent_status = 'active' 很容易漏掉关键约束。比如“订单只能在商户启用状态下创建”，但商户表里 status 是 'enabled'，而触发器里写成 = 'active' 就永远不生效。
实操建议：
- 状态值必须与业务文档严格一致，建议提取为常量变量：
SET valid_parent_status = 'enabled'; - 校验分支要覆盖全部合法值，别只写
IF NEW.parent_status != 'enabled' THEN ...，漏掉'trial'等过渡态 - 错误信息里明确写出期望值：
CONCAT('父记录状态必须为 ', valid_parent_status, '，当前为 ', NEW.parent_status) - 上线前用真实数据集跑一遍，特别检查父表中存在
NULL、空字符串、大小写混用等脏数据的情况
