MySQL和SQL Server均禁止触发器中用子查询直接更新同一张表，因引擎层为防递归与一致性破坏而强制拦截：MySQL报ERROR 1442，SQL Server报ERROR 369或事务中断；正确做法是触发器仅取值、判条件、调用存储过程，复杂逻辑交由过程处理。
触发器里不能直接写嵌套查询做数据修改
SQL Server 和 MySQL 都不允许在触发器中用子查询直接更新同一张表，比如 UPDATE t SET x = 1 WHERE id IN (SELECT id FROM t WHERE y > 0)。SQL Server 报错 ERROR 369 或事务中断；MySQL 直接拒绝执行并提示 ERROR 1442（“Can't update table in stored function/trigger”）。这不是语法问题，而是引擎层的保护机制——防止触发器递归污染或破坏一致性。
- 触发器执行时，
INSERTED/DELETED是只读虚拟表，不能被UPDATE/DELETE引用为目标表 - 哪怕子查询查的是另一张表，只要
UPDATE或INSERT的目标表和子查询里出现的表名相同，就触发限制 - MySQL 中
BEFORE触发器允许对NEW赋值，但禁止任何SELECT ... FROM same_table后再改本表
复杂逻辑必须拆到存储过程中，触发器只负责调用
把校验、查关联、状态计算、跨表更新等全塞进触发器，只会让错误变隐蔽、性能变差、调试变绝望。正确做法是：触发器只做三件事——取 NEW/OLD 值、判断是否满足调用条件、执行 CALL proc_name(...)。
- 存储过程声明为
READS SQL DATA（MySQL）或不带COMMIT（SQL Server），确保能被触发器安全调用 - 过程内用
SELECT ... FOR UPDATE锁库存、用EXISTS替COUNT(*)、用IF OLD.status != NEW.status精准捕获变更点 - 触发器里别写
IF (SELECT COUNT(*) FROM orders ...) > 0—— 这种写法在 MySQL 会报ERROR 1356，SQL Server 则可能因延迟编译导致计划缓存失效
SQL Server 嵌套触发器最多 32 层，但别真用满
SQL Server 允许 DML 触发器嵌套，上限 32 层，但这是个危险的“容错上限”，不是设计目标。一旦链中某个触发器执行 INSERT 又触发另一个同类型触发器，就计入层数——而你很难在开发阶段预判全部路径。
-
INSTEAD OF触发器不受nested triggers配置影响，始终可嵌套，但同样受 32 层硬限 - 开启
RECURSIVE_TRIGGERS后，AFTER触发器可能自我调用，形成无限循环，直到撞上 32 层后报Maximum stored procedure, function, trigger, or view nesting level exceeded - 调试时加
PRINT输出层级标识（如PRINT 'Trig2 depth: ' + CAST(@@NESTLEVEL AS VARCHAR)），否则出错时连哪一层崩了都找不到
MySQL 不支持触发器调用含事务的存储过程
MySQL 触发器本身处于隐式事务中，若被调用的存储过程里包含 START TRANSACTION 或 COMMIT，会直接报错 ERROR 1305（“PROCEDURE xxx does not exist”）或 ERROR 1303（“Cannot have a transaction active in a trigger”）。这意味着你没法靠存储过程自己控制事务边界。
- 所有数据操作必须在触发器上下文内完成，或由外层应用事务兜底
- 想实现“扣库存失败则整个 INSERT 失败”，就得在触发器里用
SELECT ... FOR UPDATE+IF NOT EXISTS+SIGNAL SQLSTATE主动抛错 - 避免在触发器里
CALL任何含INSERT/UPDATE的过程——除非该过程明确声明为CONTAINS SQL且不含事务语句
