根本原因是触发器中使用标量变量赋值（如select @id = id from inserted），多行时变量仅保留最后一行值；正确做法是将inserted/deleted视为表，通过join等集合操作批量处理。
SQL Server / MySQL 触发器批量更新只改一行，根本原因是什么
不是触发器“没跑”，而是你写的逻辑默认只处理 inserted 里的某一行——因为用了标量变量赋值，比如 SELECT @id = id FROM inserted。多行时，@id 最终只存最后一个被读取的值，其余全丢。这在单行测试时完全正常，一上生产批量导入就漏数据。
用集合操作替代变量赋值，三步改写法
把触发器当存储过程写，是最大误区；它本质是“对一批行做统一操作”的声明式逻辑。必须把 inserted 和 deleted 当成真实表来 JOIN、UPDATE、MERGE。
- ❌ 错误写法：
SELECT @id = id FROM inserted→ 只取一行，且行为不可控 - ✅ 正确写法：直接在 UPDATE 中 JOIN
inserted，例如：UPDATE t SET status = 'done' FROM target_table t INNER JOIN inserted i ON t.id = i.id;
- ✅ 校验类逻辑（如禁止负库存）用
NOT EXISTS (SELECT 1 FROM inserted i WHERE i.id = t.id AND i.qty ，而不是 <code>IF @qty
MySQL 的 BEFORE INSERT 不触发？先确认语句类型
如果你用的是 REPLACE INTO 或 INSERT ... ON DUPLICATE KEY UPDATE，那 BEFORE INSERT 触发器压根不会执行——MySQL 8.0.19 之前只走 BEFORE UPDATE 路径。这会导致你写的字段校验、默认值填充等逻辑静默失效。
- 查当前触发器是否真被调用：
INSERT INTO debug_log SELECT NOW(), 'before_insert', COUNT(*) FROM inserted; - 确认触发器定义：
SHOW TRIGGERS LIKE 'your_table';看Timing是BEFORE还是AFTER，Event是否匹配你实际执行的语句（INSERTvsUPDATE） - 想强制走 INSERT 路径：改成先
DELETE再INSERT，或改用应用层控制
游标不是解法，是性能陷阱
看到“要逐行处理”，立刻写游标遍历 inserted，这是典型救火式写法。它让原本一次完成的批量操作退化成 N 次单行事务，锁时间拉长、CPU 升高、死锁概率飙升。
- 游标在 SQL Server 中会显著放大锁竞争，尤其当
inserted有上万行时，每 fetch 一次都可能重新申请/释放锁 - 真正需要逐行副作用（如发消息、调外部 API）的场景，应把动作解耦：触发器只写入通知队列表（如
notify_queue），由独立作业轮询处理 - 如果非得在数据库内逐行计算，优先考虑窗口函数 + 临时表分批，而不是游标
最易被忽略的一点：所有测试必须用至少两行以上的语句验证，比如 INSERT INTO t VALUES (1,'a'),(2,'b');。单行测试永远过不了关，但没人会告诉你这点。
