行级触发器在批量更新时按影响行数执行n次，带来显著性能开销；mysql仅支持行级触发器，而postgresql/oracle还支持仅执行一次的语句级触发器，适用于聚合统计但无法访问单行数据。
行级触发器在批量更新时会反复执行
只要一条 UPDATE 或 INSERT 语句影响 N 行，FOR EACH ROW 触发器就会执行 N 次。每次执行都包含完整函数调用开销、变量初始化、SQL 解析（如触发器内含 INSERT INTO log_table）、事务日志写入等。哪怕逻辑只有一行赋值，N=10万时就是 10 万次独立上下文切换。
常见错误现象：UPDATE accounts SET balance = balance + 1 WHERE user_type = 'vip' 影响 8 万行，配套的行级审计触发器让该语句从 200ms 拉长到 12 秒以上。
使用场景中容易忽略的一点：MySQL **根本不支持语句级触发器**，所有触发器默认且唯一是行级；PostgreSQL 和 Oracle 才真正区分 FOR EACH ROW 与 FOR EACH STATEMENT。
语句级触发器只执行一次，但无法访问单行数据
语句级触发器（FOR EACH STATEMENT）在 PostgreSQL/Oracle 中整个 SQL 执行完后仅触发一次，适合记录“本次共更新了 X 行”这类聚合信息。但它拿不到 OLD 或 NEW 的字段值 —— 因为没有“某一行”的概念。
参数差异明显：
- 行级触发器可用：
OLD.balance、NEW.account_name、:old.created_at - 语句级触发器只能用：
ROW_COUNT()（PostgreSQL）、SQL%ROWCOUNT（Oracle），不能引用任何列
性能影响悬殊：同样 8 万行更新，语句级触发器耗时通常稳定在 1–3ms 内，和没加触发器接近。但它完全没法做逐行校验、字段变更比对或单行日志落库。
MySQL 用户别想绕过行级开销
MySQL 5.7 / 8.0 全系列 **不支持 FOR EACH STATEMENT 语法**。你写 CREATE TRIGGER ... AFTER UPDATE ON t1 BEGIN ... END，它自动按行级处理，且不允许省略 FOR EACH ROW（显式或隐式都必须存在）。
这意味着：
- 试图用 MySQL 实现“批量操作只记一条总日志”，必须改用应用层控制，或在触发器里手动维护临时计数器（不推荐，易出错）
- 如果业务强依赖单行变更细节（比如余额变动审计），MySQL 行级触发器是唯一选择，但必须接受性能代价
- 替代方案可考虑：用
INSERT ... SELECT+ 应用层分批 + 异步写日志，避开触发器路径
PostgreSQL 中混合使用更可控
PostgreSQL 允许在同一事件上同时定义行级和语句级触发器，执行顺序固定：BEFORE STATEMENT → BEFORE ROW × N → AFTER ROW × N → AFTER STATEMENT。
实操建议：
- 用行级触发器做关键字段校验（如
IF NEW.balance ） - 用语句级触发器做最终统计归档（如
INSERT INTO batch_log VALUES (now(), TG_OP, ROW_COUNT())） - 避免在行级触发器里执行
UPDATE或复杂查询 —— 容易引发锁等待或递归触发
真正容易被忽略的是：语句级触发器里的 ROW_COUNT() 返回的是当前触发语句影响的行数，不是事务内累计值；而行级触发器中 NEW/OLD 在 UPDATE 为空值列上可能为 NULL，需显式判空，否则整批失败。
