MySQL的FOR EACH ROW触发器在批量INSERT中逐行触发3次，而SQL Server和PostgreSQL的DML触发器默认语句级、仅触发1次；关键在于按数据库特性用集合操作（如SELECT FROM inserted）而非单行变量赋值处理多行数据。
MySQL 的 FOR EACH ROW 触发器在批量 INSERT 中**确实逐行触发**，而 SQL Server 和 PostgreSQL 的 DML 触发器是**语句级、只触发一次**——你遇到“只触发一次”，大概率用的是 SQL Server 或误判了 MySQL 行为。关键不是“怎么让它多触发”，而是“怎么正确处理多行数据”。
确认你用的是哪种数据库和触发器类型
这是所有问题的前提，混淆这点会直接写错逻辑：
- MySQL：只有行级触发器，
FOR EACH ROW是强制的，INSERT INTO t VALUES (1),(2),(3)会调用触发器 3 次；INSERT ... SELECT也会对结果集每一行触发一次 - SQL Server / PostgreSQL：DML 触发器默认是语句级，
INSERT影响 N 行，触发器只执行 1 次，inserted表里有全部 N 行 —— 这才是“只触发一次”的真实场景 - 错误现象示例：
SELECT @id = id FROM inserted在 SQL Server 中，@id 最终只存一个值（非随机，但不可控），其余行被丢弃；在 MySQL 中这句语法根本报错，因为没FROM子句不能直接赋值
SQL Server 中避免变量赋值丢失多行数据
别把 inserted 当单行结果集用，它是一张临时表，必须当集合处理：
- ❌ 错误写法：
DECLARE @id INT; SELECT @id = id FROM inserted;—— 只取一行，逻辑残缺 - ✅ 正确写法一（集合插入）：
INSERT INTO audit_log (record_id, action) SELECT id, 'INSERT' FROM inserted;—— 一行 SQL 完成全部写入 - ✅ 正确写法二（关联更新）：
UPDATE t SET status = 'processed' FROM target_table t INNER JOIN inserted i ON t.id = i.id; - ⚠️ 游标不是解法而是退路：虽然能遍历
inserted每一行，但性能差、易锁表、并发下不稳定，仅限极少数必须串行调用外部 API 的场景
MySQL 中批量插入触发器性能崩盘的真实原因
它确实逐行触发，但“逐行”不等于“可控”——性能瓶颈常来自触发器内部设计：
- 触发器内任何
SELECT查询（哪怕SELECT COUNT(*) FROM config）都会让单行开销从 0.2ms 升至 5ms+，10 万行就是 500 秒 -
NEW和OLD不支持索引，触发器里JOIN其他表极易全表扫描 - 每行触发都调一次
NOW()、UUID()等函数，高并发下系统时钟调用堆积成卡顿 - 替代方案优先级：生成列（
created_at DATETIME AS (NOW()) STORED） >DEFAULT CURRENT_TIMESTAMP> BEFORE INSERT 触发器
真正需要逐行副作用时，别硬扛在触发器里
比如发邮件、调用 HTTP 接口、写 Kafka 消息——这些操作天然不适合数据库事务上下文：
- 触发器中同步调用会导致事务变长、锁持有时间拉长、超时风险飙升
- 推荐做法：触发器只做最轻量的事，例如
INSERT INTO notify_queue (table_name, pk_id, event_type) SELECT 'orders', order_id, 'created' FROM inserted; - 由外部作业（如 SQL Server Agent Job、Python 轮询脚本、Flink CDC）消费队列表，异步执行重操作
- 这样既保证主流程高性能，又不丢事件，还能重试、限流、监控失败
最容易被忽略的是：很多人花几周优化触发器里的索引、缓存、拆函数，却没意识到问题根源在于“让触发器承担了它不该干的事”。校验用 CHECK CONSTRAINT，默认值用 DEFAULT，审计日志用 INSERT ... SELECT 集合写入，复杂流程交给应用层或队列——留下的才是触发器该干的：原子、确定、毫秒级完成的轻量数据修正。
