MySQL 8.0+ 和 PostgreSQL 默认禁止在触发器中直接修改当前表，以防隐式递归；MySQL 需用事件调度器或应用层补偿绕过，PostgreSQL 可在 BEFORE 触发器中修改 NEW 行，但 AFTER 中禁止 DML。
触发器里改本表为什么会报错
MySQL 8.0+ 和 PostgreSQL 默认禁止在 BEFORE 或 AFTER 触发器中直接修改当前表，否则会抛出类似 Can't update table't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger 的错误。这不是语法问题，而是数据库为防止隐式递归做的硬性保护——哪怕你没写 UPDATE t，只要触发器执行路径中可能间接导致本表再次被 DML 影响（比如调用含 INSERT INTO t 的存储过程），就会拦截。
常见误判场景：
– 认为只读查询（SELECT）不会触发限制 → 实际上某些优化器路径或事务隔离级别下，SELECT …… FOR UPDATE 也可能被拦
– 在 AFTER INSERT 里做 UPDATE t SET x = y WHERE id = NEW.id → 明确违反规则，立刻报错
– 使用 INSERT IGNORE 或 REPLACE INTO 写本表 → 同样算“修改本表”，不豁免
MySQL 中绕过循环更新的三种可行方式
核心思路是把“对本表的写操作”从触发器上下文中移出去，交给异步或外部机制完成。没有“安全又透明”的同步方案，只有取舍。
- 用
INSERT DELAYED（仅旧版 MySQL 5.6 及以前支持，已弃用，不推荐） - 改用事件调度器（
EVENT）：触发器里只插入一条日志到中间表，再由每秒轮询的EVENT拉取并执行真实更新 —— 延迟毫秒级到秒级，适合非实时场景 - 改用应用层补偿：触发器里只发消息（如写 Kafka / Redis Stream / 文件），由独立消费者进程处理后续更新 —— 解耦最干净，但引入外部依赖
注意：SET SQL_LOG_BIN = 0 或禁用二进制日志不能绕过该限制，它只影响复制，不解除触发器执行时的表锁定检查。
PostgreSQL 怎么安全地在触发器里改本表
PostgreSQL 允许在 BEFORE 触发器中修改 NEW 行（即“行级变更”），这是合法且常用的模式；但禁止在 AFTER 触发器中执行任何 DML 操作（包括 INSERT/UPDATE/DELETE 当前表）。关键分水岭是：是否需要“基于刚插入的完整行数据做另一条记录的写入”？
- 如果只是修正当前行字段（如自动填充
created_at、标准化email）→ 用BEFORE INSERT OR UPDATE+ 修改NEW.xxx即可，零风险 - 如果要根据新插入的订单生成对应库存流水 → 必须拆成两个动作：触发器里不做
INSERT INTO inventory_log，改用PERFORM pg_notify(……)通知监听端，由外部程序执行 - 不要试图用
EXECUTE 'INSERT ……'动态拼 SQL 绕过检查 —— PostgreSQL 在解析阶段就识别目标表名，照样报错relation "t" does not exist（因执行上下文无权访问）
真正容易被忽略的并发陷阱
即使绕过了语法报错，多个会话同时触发同一逻辑仍可能引发数据错乱。比如两个并发 INSERT 都想根据当前最大 sort_order 设置新值，结果写入相同序号。
这类问题不会报错，但结果不可控。解决它不靠触发器本身，而靠：
- 在应用层用
SELECT …… FOR UPDATE显式加锁（需确保事务包裹整个读 - 算 - 写流程） - 改用原子操作：如 PostgreSQL 的
INSERT …… ON CONFLICT DO UPDATE，或 MySQL 的INSERT …… ON DUPLICATE KEY UPDATE - 放弃“自增序号”类业务逻辑，改用数据库原生
SEQUENCE或应用分配 UUID
触发器不是事务协调器，它只负责单行上下文内的轻量响应。一旦涉及跨行状态依赖，就得让出控制权。
