在 mysql 中，订单表的 delete 触发器无法删除关联的订单项，因触发器禁止修改自身触发表；唯一可行方案是在 orders 表上创建 after delete 触发器执行子表删除，但其不参与事务回滚，易致数据不一致，故推荐优先使用外键 on delete cascade。
触发器里用 DELETE 语句删关联数据，为什么没生效？
因为 MySQL 触发器不能修改触发它的同一张表——BEFORE DELETE 或 AFTER DELETE 中对主表再执行 DELETE，会直接报错 Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。
所以“在订单表的 DELETE 触发器里删订单项”这种写法必然失败。必须换思路：把级联逻辑转移到被引用表（子表）上，或者改用 AFTER 触发器 + 应用层兜底。
- 真正能安全执行级联删除的，是定义在**被引用表**（如
order_items）上的BEFORE DELETE触发器，检查其order_id是否还在orders表中；但这是“防孤立项”，不是“删子项” - 如果目标是删
orders时自动清空order_items，唯一可行路径是：在orders上建AFTER DELETE触发器，里面调用DELETE FROM order_items WHERE order_id = OLD.id -
AFTER触发器不参与事务回滚判断，如果后续语句出错，子表删除已发生，可能造成数据不一致
用 AFTER DELETE 触发器做级联，要注意哪些事务陷阱？
MySQL 的触发器默认属于外层语句的事务，但 AFTER 触发器里的操作一旦执行就不可逆，哪怕外层事务最终 ROLLBACK，它也不会回滚。
比如你在一个事务里删一条订单，触发器顺手删了 10 条订单项；接着下一句 SQL 报错导致整个事务回滚——订单记录恢复了，但那 10 条订单项已经没了。
- 这不是 bug，是 MySQL 明确文档行为：
AFTER触发器在语句提交后才执行，不参与语句级原子性 - 想规避？只能把级联逻辑提到应用层，在同一个事务里手动
DELETE FROM order_items WHERE order_id = ?再DELETE FROM orders WHERE id = ? - 如果坚持用触发器，至少加个
SELECT COUNT(*)验证OLD.id是否真被删了，避免误删（比如触发器被其他非事务操作调用）
替代外键的触发器，性能和维护成本到底高在哪？
外键由引擎原生支持，约束检查在内存中完成，基本无额外开销；而触发器是 SQL 解释执行，每次 DELETE 都要启动、解析、运行一段逻辑。
尤其当子表数据量大、或触发器里有子查询时，延迟会明显上升。更麻烦的是调试：错误不会出现在业务 SQL 行号里，而是藏在触发器定义中，且 SHOW WARNINGS 很难捕获静默失败。
- 一个
AFTER DELETE触发器里写了DELETE ... JOIN，在 MySQL 5.7 下可能因优化器 Bug 导致全表扫描 - 触发器无法被 ORM 工具识别，Laravel/Ecto 等框架的软删除、审计日志功能可能绕过它
- 备份还原时，
mysqldump --triggers默认不导出触发器，容易漏配，上线后级联失效却查不出原因
什么时候真该放弃外键，硬上触发器？
只有两种现实场景值得考虑：跨库表关联（MySQL 原生外键不支持），或者需要在级联时附带复杂逻辑（比如删订单前先检查是否已发货、生成归档快照、调用 UDF 发通知）。
除此之外，所有“只是想自动删子记录”的需求，都该优先用外键的 ON DELETE CASCADE。别信“外键影响性能”的陈旧说法——现代 MySQL 在索引到位的前提下，外键检查开销几乎可忽略。
真要用触发器，务必做到：命名带业务前缀（如 trg_orders_after_delete_cascade）、注释写清事务边界、在测试环境压测子表万级数据下的响应时间。不然线上第一个并发 DELETE 就会让你翻出慢日志。
