触发器中不能直接使用UPDATE...JOIN（MySQL）或UPDATE...FROM（PostgreSQL），因上下文隔离限制；应改用业务层批量处理、临时表缓冲或CTE伪批量，并注意索引与事务死锁风险。
触发器里不能直接用 UPDATE ... JOIN 语法
MySQL 5.7+ 和 PostgreSQL 的触发器函数里，UPDATE ... JOIN（MySQL）或 UPDATE ... FROM（PostgreSQL）在触发器中常被误认为可用，但实际受限：MySQL 触发器中禁止对「正在被修改的表」做任何显式 SELECT/UPDATE（会报 Can't update table 'xxx' in stored function/trigger），PostgreSQL 则要求明确指定目标表别名且不能引用 NEW/OLD 行的字段做子查询关联更新——本质是触发器执行上下文隔离导致的限制。
实操建议：
- 改用游标（PostgreSQL）或循环变量（MySQL 存储过程式触发器）逐行处理，但性能差，仅适用于低频小批量场景
- 更推荐：把批量逻辑移出触发器，在业务层或定时任务中用带
IN或JOIN的单条语句完成，触发器只负责记录变更意图（如写入临时日志表） - 若必须留在触发器内，MySQL 可用
INSERT INTO ... ON DUPLICATE KEY UPDATE模拟批量效果（需主键/唯一键支撑）
用临时内存表暂存待更新 ID 再批量处理
这是绕过 MySQL 触发器限制最稳妥的方式：不直接更新从表，而是先将需要变更的从表 ID 插入一个 MEMORY 引擎临时表，再在触发器外由事件或应用读取并执行真正更新。
示例（MySQL）：
CREATE TABLE IF NOT EXISTS trigger_pending_updates ( child_id BIGINT NOT NULL, new_status VARCHAR(20) NOT NULL, PRIMARY KEY (child_id) ) ENGINE=MEMORY;
在触发器中：
INSERT INTO trigger_pending_updates (child_id, new_status) SELECT c.id, 'archived' FROM child_table c WHERE c.parent_id = NEW.id;
注意点：
-
MEMORY表重启即丢，适合瞬时缓冲；生产环境建议改用持久表 + 清理机制 - 避免在高并发下出现 ID 冲突，加
ON DUPLICATE KEY UPDATE或用REPLACE INTO - 务必配套定时清理逻辑，否则
trigger_pending_updates会越积越多
PostgreSQL 中用 FOR EACH ROW + 批量 CTE 实现伪批量
PostgreSQL 触发器本身不支持“批量触发”，但可以利用 WITH 语句在单次触发中完成多行更新——前提是你的触发逻辑能聚合出一批待更新的 child_id。常见于父表状态变更影响多个子记录的场景。
示例（假设父表 order 更新 status，需同步更新 order_item 中对应项的 sync_status）：
CREATE OR REPLACE FUNCTION sync_child_status()
RETURNS TRIGGER AS $$
BEGIN
WITH target_items AS (
SELECT id FROM order_item WHERE order_id = NEW.id
)
UPDATE order_item
SET sync_status = 'pending'
WHERE id IN (SELECT id FROM target_items);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
关键限制：
- 该写法仍属于“单次触发内执行一次 UPDATE”，不是真正的批量触发，但避免了循环开销
- 不能在
BEFORE触发器中做 DML 操作，必须用AFTER - 若子表数据量大，
IN (SELECT ...)可能比JOIN慢，必要时改用EXISTS或物化中间结果
最容易被忽略的事务边界和死锁风险
触发器里的更新操作和主事务共享同一事务上下文，一旦触发器中执行耗时更新或锁范围过大，极易引发死锁或长事务阻塞。尤其当父表更新频繁、从表有二级索引未覆盖查询条件时，UPDATE 会锁住整页甚至整个分区。
规避方式：
- 确保从表上存在高效索引，例如
child_table(parent_id)，否则WHERE parent_id = NEW.id会全表扫描加锁 - 避免在触发器中调用外部服务、写文件、发消息等非 SQL 操作
- MySQL 下慎用
FOR EACH ROW触发器处理大批量INSERT ... SELECT，可能让触发器重复执行数百次 - 上线前用
SHOW ENGINE INNODB STATUS或pg_stat_activity观察锁等待链
真正棘手的从来不是语法怎么写，而是你没意识到那条看似简单的 UPDATE 正在锁住整个子表的下一个插入动作。
