外键约束报错是因为触发器执行早于外键级联动作，手动删子表时父记录尚未删除，外键检查仍生效；需禁用ON DELETE CASCADE、设为BEFORE DELETE、控制嵌套深度并确保权限与SQL正确性。
触发器里写 DELETE 时，为什么外键约束反而报错？
因为触发器执行时机早于外键级联动作，而你又在触发器里手动删子表——此时父记录还没真正被删，外键检查仍生效，DELETE FROM child_table WHERE parent_id = ? 会撞上“子记录存在，父记录不能删”的约束。根本不是触发器没生效，是它和外键在打架。
- 先禁用对应外键的
ON DELETE CASCADE，否则触发器根本不会被调用（数据库直接走外键逻辑了） - 确保触发器定义为
BEFORE DELETE，不是AFTER；AFTER里删子表，父行已删，但子表可能还残留引用，反而引发一致性问题 - PostgreSQL 需显式声明
FOR EACH ROW，MySQL 8.0+ 默认支持，但老版本要检查是否启用sql_mode中的STRICT_TRANS_TABLES，否则静默失败
多层关联（A→B→C→D）怎么避免触发器嵌套爆炸？
每删一层都触发一次新 DELETE，A 删 B，B 删 C，C 删 D……最后可能栈溢出或锁表太久。关键不是“全链写进一个触发器”，而是控制清理边界和顺序。
- 只在最顶层表（如
orders）上建BEFORE DELETE触发器，里面用单条语句清掉所有直系子表（order_items,order_logs），别让子表自己再触发 - 对深层子表（比如
item_attachments），改用ON DELETE CASCADE或定时任务异步清理，不塞进主事务链 - PostgreSQL 可用
pg_trigger_depth()检查当前嵌套深度，>1 就直接 return，防意外递归
触发器中执行 DELETE 失败却不报错，数据残留怎么办？
MySQL 默认忽略触发器内的 SQL 错误，PostgreSQL 则会中断整个事务——但两者都可能让你误以为“删干净了”。真正的问题常藏在权限、隔离级别或隐式类型转换里。
- MySQL 触发器内
DELETE报ERROR 1442 (HY000)：不能修改触发该触发器的表，得用临时表或存储过程绕开 - 检查触发器用户是否有子表的
DELETE权限，尤其跨 schema 时，DEFINER用户权限不足会导致静默跳过 - WHERE 条件里用了函数（如
UNIX_TIMESTAMP(created_at) ），可能因索引失效导致删不全，改用原生日期比较：<code>created_at
用触发器做业务级清理，比应用层删除慢很多？
不是触发器天生慢，是它把原本可批量、可异步的清理，硬拖进了主事务。每次删 1 行订单，就同步删 50 行子项，IO 和锁都卡在一条线上。
- 触发器里别用循环（
WHILE/LOOP），一律改写成集合操作：DELETE FROM logs WHERE order_id IN (SELECT id FROM OLD) - 大表清理前加
EXPLAIN看执行计划，确保order_id有索引；没索引的字段（如状态标记）慎作清理条件 - 如果日均删超 1000 单，触发器就该退场了——改用应用层发消息到队列，由 worker 异步分批删，主流程不等结果
真正在生产扛住复杂关联删除的，从来不是靠触发器写得多深，而是清楚哪层必须强一致（比如财务凭证），哪层可以弱一致（比如操作日志）。越想“一删到底”，越容易在事务边界上翻车。
