DELETE触发器无法捕获级联删除动作，因ON DELETE CASCADE由InnoDB引擎层直接执行、绕过SQL层，子表DELETE触发器完全不执行；唯一可靠响应点是父表的BEFORE/AFTER DELETE触发器。
DELETE 触发器不能直接捕获被删主表的关联从表数据
触发器运行在单表上下文中，DELETE 语句作用于主表（比如 orders）时，触发器内部只能访问主表的 OLD 行，无法自动“看到”或“查到”从表（如 order_items）里那些外键指向它的记录。想靠一个主表上的 DELETE 触发器顺手把从表数据也备份走，不加显式查询是做不到的。
常见错误现象：Cannot reference table 'order_items' from within trigger on 'orders'（MySQL 8.0+ 严格模式下会明确报错；旧版本可能静默失败或行为异常）。
所以必须主动查——但得小心时机和权限：
- 用
SELECT ... INTO或循环插入前，确保触发器有对从表的SELECT权限 - 避免在
BEFORE DELETE中做耗时查询，否则阻塞主表删除操作 -
AFTER DELETE更安全，但此时主表行已删，OLD仍可用，只是要靠外键值去反查从表
用 AFTER DELETE + 显式 JOIN 查询实现备份
假设主表 orders(id, customer_id)，从表 order_items(order_id, product_id, qty)，外键 order_items.order_id → orders.id。目标是在删 orders 时，把对应所有 order_items 插入备份表 order_items_archive。
实操建议：
- 备份表结构需与原从表一致，且额外加字段如
archived_at DATETIME DEFAULT NOW()、deleted_order_id BIGINT - 触发器中用
INSERT INTO order_items_archive SELECT ... FROM order_items WHERE order_id = OLD.id - 不要用子查询包裹整个
SELECT，MySQL 不允许在触发器中对触发表做 DML，但对其他表可以
示例片段（MySQL）：
CREATE TRIGGER backup_order_items_on_order_delete
AFTER DELETE ON orders
FOR EACH ROW
INSERT INTO order_items_archive
SELECT *, NOW(), OLD.id
FROM order_items
WHERE order_id = OLD.id;
外键约束会干扰触发器执行顺序
如果从表设置了 ON DELETE CASCADE，那么主表 DELETE 一执行，数据库会先删掉所有匹配的 order_items 行——等触发器运行时，已经查不到任何数据了。
必须调整外键行为：
- 改成
ON DELETE RESTRICT或ON DELETE NO ACTION（二者在 MySQL 中等效），让删除主表前先检查从表是否有残留，从而把控制权交还给触发器 - 或者干脆去掉外键级联，改由应用层或触发器统一管理生命周期
- 注意：修改外键需
DROP FOREIGN KEY再ADD CONSTRAINT，不是改ALTER COLUMN
验证是否生效：手动 DELETE FROM orders WHERE id = X 后查 order_items_archive，确认有数据；再查 order_items，应为空（说明级联没触发，触发器接管了）。
多从表场景下触发器性能和事务边界要盯紧
一个主表关联 3 个从表？别堆 3 个独立 INSERT ... SELECT。每次查询都走一次全表扫描（哪怕加了索引，WHERE 条件能命中，但触发器里反复查仍是开销），更麻烦的是：这些操作不在同一个事务上下文里隐式提交——万一第二个备份失败，第一个已写入，没法回滚。
更可控的做法：
- 把多个从表备份逻辑封装进一个存储过程，用
START TRANSACTION包裹，显式COMMIT/ROLLBACK - 触发器里只调用该存储过程：
CALL backup_related_tables(OLD.id) - 确保存储过程中所有
INSERT都针对归档表，不碰原业务表
容易被忽略的一点：MySQL 触发器不支持 SAVEPOINT，所以嵌套事务不可行；归档失败时，主表删除已完成，只能靠后续人工修复或告警机制补救。
