mysql触发器禁止操作正在被修改的表，before中仅可修改new字段，after中连select都不允许；跨表需用带limit 1的标量子查询；汇总逻辑须降维至单行；insert/update/delete需分设触发器；oracle和sql server同有类似限制。

MySQL触发器里不能直接SELECT或UPDATE被修改的表

报错 ERROR 1442 或 Can't update table 't1' in stored function/trigger 是最常见症状。MySQL 严格禁止在触发器中对当前正在被语句修改的表做任何读写操作——哪怕只是 SELECT 一行，或想用 JOIN 关联它。

• BEFORE UPDATE 中只能安全修改 NEW 字段（如 SET NEW.updated_at = NOW()）
• AFTER INSERT/UPDATE/DELETE 中连 SELECT FROM t1 都不行，更别说 UPDATE t1
• 想查本表历史状态？不行。想根据本表其他行数据补全当前行？也不行
• 唯一合法路径：把需要的数据提前算好、传进来（应用层带值），或改用定时任务/事件异步处理

跨表操作必须用标量子查询，不能用JOIN语法

想根据 users 表的状态更新当前订单的 status？别写 UPDATE orders JOIN users ... —— 触发器不支持这种写法，会报错“subquery returns more than 1 row”或解析失败。

• 正确写法是：用单值子查询赋给 NEW.status，例如 SET NEW.status = (SELECT IF(t2.is_active, 'online', 'offline') FROM users t2 WHERE t2.id = NEW.user_id LIMIT 1)
• LIMIT 1 必须加，否则多匹配直接中断触发器执行
• 子查询结果必须唯一，建议在 users.id 上建主键或唯一索引保障
• 高并发下子查询慢会拖垮主 SQL，尤其当 users 表无合适索引时

AFTER触发器更新汇总表时不能含聚合或GROUP BY

触发器运行在单行上下文，OLD 和 NEW 只能看到当前这一行。你没法在 orders 的触发器里跑 SELECT COUNT(*) FROM orders JOIN users ... GROUP BY month。

• 汇总逻辑必须降维到单点：比如只查 NEW.user_id 对应的用户等级，再决定是否给 summary_vip_count 加 1
• 避免任何 COUNT、SUM、GROUP BY、嵌套子查询统计
• INSERT/UPDATE/DELETE 三类操作要拆成三个独立触发器，各自处理增、改、删对汇总值的影响方向
• 汇总表主键必须覆盖全部统计维度（如 (year_month, region, level)），否则 INSERT ON DUPLICATE KEY UPDATE 会失效

Oracle 和 SQL Server 的多表关联死锁风险更高

Oracle 报 ORA-04091: table is mutating，SQL Server 出现 Deadlock encountered，本质都是事务锁顺序混乱 + 触发器内访问路径不可控。

• Oracle：禁止在 BEFORE 行级触发器里 SELECT FROM 触发表，改用 :OLD/:NEW 伪记录；真要读本表快照，得上 PRAGMA AUTONOMOUS_TRANSACTION（但会脱离原事务，慎用）
• SQL Server：确保所有触发器内 DML 按固定顺序访问表（如总先 UPDATE parent 再 UPDATE child），避免依赖存储过程调用
• 两者都受隔离级别影响：READ COMMITTED 下可能被阻塞，READ UNCOMMITTED 可缓解但引入脏读

触发器不是万能胶，它天然受限于单行上下文、无事务控制、隐式锁放大等硬约束。真正复杂的多表联动，往往卡在“以为能写JOIN，其实只能查一行”这个认知断层上。