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 可缓解但引入脏读
