是的，MySQL触发器按行触发（FOR EACH ROW），NEW仅代表当前行，无法直接处理多行结果集；禁止在触发器中使用SELECT...INTO获取多行数据，也不应尝试聚合统计，须确保单行校验与赋值逻辑自洽。
触发器里不能用 SELECT ... INTO 处理多行？
是的，SELECT ... INTO（尤其在 PostgreSQL 或 PL/pgSQL 中）要求查询结果恰好一行一列，批量插入/更新时触发器拿到的是多行数据，直接用会报错 more than one row returned by a subquery used as an expression。MySQL 的 INSERT ... SELECT 虽不报这个错，但若在 BEFORE 触发器里试图把整批新行塞进单个变量，逻辑就崩了。
根本问题不是语法限制，而是触发器执行粒度：它按「每一行」触发（FOR EACH ROW），不是按「每一批」。所谓“批量操作支持”，其实是靠正确利用这一特性，而不是强行在触发器里聚合多行。
- 别在触发器里写
SELECT * FROM NEW——NEW和OLD是行级记录，不是结果集 - 需要跨行逻辑（比如检查本次插入是否违反全局唯一约束），得改用约束、物化视图或应用层预检，别硬塞进触发器
- PostgreSQL 可用
WHEN (condition)对每行单独过滤，但条件里不能引用其他行
MySQL 中如何让 BEFORE INSERT 触发器处理批量 INSERT？
MySQL 的 INSERT INTO t VALUES (...), (...), (...) 会为每一行分别触发一次 BEFORE INSERT，NEW 始终只代表当前正在插入的那一条。这意味着你不需要额外循环，也不该尝试用游标遍历——那是反模式。
常见误区是想在触发器里统计本次插入总行数或求和，这既不可靠（并发下不准），也无必要（应用层或存储过程更合适）。真正要做的，是确保单行逻辑自洽：
- 用
IF NEW.status IS NULL THEN SET NEW.status = 'pending'; END IF;统一补默认值 - 用
IF NEW.amount 做单行校验 - 避免在触发器里调用
SELECT COUNT(*) FROM same_table WHERE ...—— 易导致死锁或幻读
PostgreSQL 的 FOR EACH ROW 触发器能访问整个语句影响的行数吗？
不能。PostgreSQL 触发器没有内置变量告诉你这次 UPDATE 影响了多少行。如果你真需要这个数字（比如日志计数），必须换思路：pg_stat_statements 查执行摘要，或在应用层记录 GET DIAGNOSTICS row_count = ROW_COUNT（仅限 PL/pgSQL 函数内，非触发器）。
有人试图用临时表 + tg_name 标记来“模拟”批处理上下文，但这是危险操作：事务未提交前临时表对其他会话不可见，且无法保证触发器执行顺序，极易出错。
- 触发器内可安全使用
tg_op（'INSERT'/'UPDATE'）、tg_table_name判断上下文 - 跨行聚合逻辑（如“本次更新后该用户总积分不能超 10000”）应拆解为单行约束 + 应用层原子更新，或用
DEFERRED CONSTRAINT延迟到事务末验证 - 若必须审计批量操作，建议在应用层生成唯一批次 ID，写入主表字段，再由触发器记录该 ID —— 这比在 DB 层猜“哪几行是一批”靠谱得多
触发器性能瓶颈常被忽略的点
批量操作下，触发器性能恶化往往不是因为逻辑复杂，而是因为它被重复执行了 N 次，每次还带 IO 或锁竞争。比如在 BEFORE UPDATE 里查另一张配置表，1000 行更新就会查 1000 次。
- 把静态配置缓存到触发器内的变量（MySQL）或
pg_settings（PostgreSQL），避免重复查询 - 避免在触发器里写日志到文件或远程服务 —— 这会让事务变慢且不可靠
- MySQL 8.0+ 支持触发器内调用函数，但函数若含
SELECT，仍受行级执行放大影响；不如把校验逻辑前置到应用或存储过程 - PostgreSQL 的
AFTER触发器若含INSERT INTO audit_log，记得给audit_log加合适索引，否则批量写入可能卡住主表
批量场景下，触发器只是单行守门员，不是批处理器。越想让它干批量的活，越容易掉进一致性、性能和可维护性的坑里。
