before insert不能更新余额表，会触发error 1442；唯一安全路径是after insert更新其他表（如balance），需用join防误更新、判null防异常、建唯一索引保准确性。
BEFORE INSERT 不能直接更新余额表，会报 ERROR 1442
触发器里对正在被操作的表做 UPDATE、SELECT FOR UPDATE 或任何写操作，都会触发 ERROR 1442 (HY000)。比如在 transaction_log 表上建 BEFORE INSERT 触发器，然后试图 UPDATE balance SET amount = amount + NEW.amount WHERE user_id = NEW.user_id —— 这条语句会立刻失败。
根本原因是：MySQL 不允许在触发器中修改当前语句正涉及的表（哪怕目标行不同），这是硬性限制，不是配置问题。
- 唯一安全路径是用
AFTER INSERT，且只更新**其他表**（如balance） - 若必须校验（如判断余额是否足够扣减），只能放在
BEFORE阶段，用SIGNAL中断，不能改余额 -
NEW和OLD是只读引用，不能赋值给其他表字段，只能用于条件判断或插入值
AFTER INSERT 触发器更新余额的正确写法
真正能落地的方案是监听流水表（如 transaction_log）的插入动作，在 AFTER INSERT 中更新余额表。但必须绕开递归和空值陷阱：
- 用
JOIN而非WHERE：避免user_id为空或不存在时静默失败或误更新整表UPDATE balance b JOIN transaction_log t ON b.user_id = t.user_id SET b.amount = b.amount + t.amount WHERE t.id = NEW.id; - 加
IF NEW.user_id IS NULL THEN LEAVE proc_label; END IF;防止 NULL 导致意外行为 - 余额字段必须声明为
NOT NULL DEFAULT 0，否则NULL + 数字结果为NULL - 确保
balance(user_id)有唯一索引，防止多行匹配导致重复加减
为什么不能靠触发器保证转账一致性
一笔转账包含两条流水：“A 扣减”和“B 增加”。即使两个 AFTER INSERT 触发器都成功执行，也无法保证原子性：
- 如果第二条插入失败，第一条已更新的余额无法回滚——触发器不参与主事务的回滚控制
- 两个触发器并发执行时，可能同时读到旧余额并各自计算，造成超扣或少加（典型竞态）
- 触发器无法感知跨语句事务边界，
START TRANSACTION内的多条INSERT对它来说是独立事件
真正可靠的做法是：应用层用显式事务包裹两条 INSERT + 一次 UPDATE balance，失败则整体回滚；触发器只作兜底校验或异步对账任务生成。
别忽略批量插入跳过触发器这个事实
INSERT INTO transaction_log VALUES (), ();、LOAD DATA INFILE、ORM 的 bulk_create 默认**完全跳过触发器**——这不是 bug，是 MySQL 明确设计的行为。
这意味着：
- 日常导入历史数据、后台补单等场景，余额不会自动更新
- 不能假设“只要建了触发器，所有插入都生效”，必须检查导入路径是否走单行插入
- 若必须支持批量，要么拆成循环单条（性能差），要么在应用层额外调用更新逻辑，或用定时任务扫描未处理流水
最易被忽略的一点：开发时用 INSERT ... VALUES 测试触发器正常，上线后用批量导入，余额就停更了——得提前约定数据写入路径与触发器的适配关系。
