必须禁用ON DELETE CASCADE并改用BEFORE DELETE触发器手动清理子表，因外键级联与触发器执行时机冲突：前者在AFTER阶段自动执行，后者若在BEFORE中删子表则外键检查仍生效而报错，若在AFTER中删又导致孤儿记录或一致性问题。
触发器不能和外键级联共存，否则会互相冲突甚至报错——必须禁用 ON DELETE CASCADE，改用 BEFORE DELETE 触发器手动清理子表。
为什么触发器里删子表反而触发外键报错？
根本不是触发器没生效，是它和外键在“抢时机”：外键的 ON DELETE CASCADE 会在 AFTER DELETE 阶段自动执行；而你若在 AFTER DELETE 触发器里再删子表，父行已删、子表引用却还没清完，可能违反一致性；更常见的是你在 BEFORE DELETE 里删子表，但外键约束仍处于激活状态，此时 DELETE FROM child_table WHERE parent_id = ? 就会撞上“子记录存在，父记录不能删”的检查。
- 必须先用
ALTER TABLE child_table DROP FOREIGN KEY fk_name移除外键的ON DELETE CASCADE - 确保触发器定义为
BEFORE DELETE，不是AFTER - PostgreSQL 需显式写
FOR EACH ROW；MySQL 8.0+ 默认支持，但老版本要确认sql_mode含STRICT_TRANS_TABLES，否则错误静默失败
多层关联（A→B→C→D）怎么避免触发器嵌套爆炸？
别让每张子表都挂触发器——A 删 B、B 删 C、C 删 D，层层触发容易栈溢出或锁表太久。关键不是“全链塞进一个触发器”，而是控制清理边界。
- 只在最顶层表（如
orders）建BEFORE DELETE触发器 - 触发器内用单条语句清掉所有直系子表：
DELETE FROM order_items WHERE order_id = OLD.id、DELETE FROM order_logs WHERE order_id = OLD.id - 深层子表（如
item_attachments）改用ON DELETE CASCADE或异步任务清理，不塞进主事务链 - PostgreSQL 可用
pg_trigger_depth()检查嵌套深度，>1 就直接RETURN防递归
触发器里 DELETE 失败却不报错，数据残留怎么办？
MySQL 默认忽略触发器内 SQL 错误，PostgreSQL 则中断整个事务——但两者都可能让你误以为“删干净了”。真正问题常藏在权限、隔离级别或隐式类型转换里。
- 检查触发器执行用户是否有子表
DELETE权限（不只是 SELECT） - 避免在触发器里用
SELECT ... INTO或临时表，易受事务隔离级别影响 - 字段类型必须严格一致：比如父表
id是BIGINT UNSIGNED，子表外键也得是BIGINT UNSIGNED，否则WHERE parent_id = OLD.id可能因隐式转换失效 - 上线前用
SHOW CREATE TRIGGER trigger_name确认定义，再手动INSERT测试数据、DELETE验证是否真删
复杂点不在语法本身，而在时机控制和层级解耦——外键和触发器不能混用，清理深度要人工划定，且每一层的执行权限和类型匹配都得亲手验过，漏一项就可能留脏数据。
