不能直接用on delete cascade，因其隐式执行、难审计、易误删整条依赖链；生产中常被dba禁用，或受限于存储引擎（如myisam不支持）、多父表场景等。
为什么不能直接用 ON DELETE CASCADE？
很多数据库确实支持 ON DELETE CASCADE，但生产环境常被禁用：它隐式执行、难以审计、容易误删整条关联链；DBA 可能全局禁用外键，或你面对的是不支持级联的存储引擎（如 MySQL MyISAM），又或者子表有多个父表、无法简单定义单一外键行为。
用 DELETE ... JOIN 清理孤立子表数据（MySQL / MariaDB）
这是最常用、可控性强的手动方案。核心是先定位「无对应父记录」的子表行，再删除。
- 假设父表为
orders（主键id），子表为order_items（外键order_id） - 执行前务必确认
order_items.order_id有索引，否则JOIN或NOT IN会极慢 - 安全写法（推荐）：
DELETE oi FROM order_items oi LEFT JOIN orders o ON oi.order_id = o.id WHERE o.id IS NULL;
- 避免用
NOT IN (SELECT id FROM orders)：若orders.id含NULL，整个条件恒为UNKNOWN，结果为空——这是高频翻车点
PostgreSQL 怎么做？用 USING 和 NOT EXISTS
PostgreSQL 不支持 DELETE ... JOIN 语法，得换路子。
- 标准写法（语义清晰、性能好）：
DELETE FROM order_items WHERE NOT EXISTS (SELECT 1 FROM orders WHERE orders.id = order_items.order_id);
- 也可用
USING模拟 JOIN：DELETE FROM order_items USING (SELECT id FROM orders) AS o WHERE order_items.order_id NOT IN (SELECT id FROM orders);
但注意：仍要警惕NOT IN遇NULL失效问题，优先选NOT EXISTS - 若子表极大，建议分批删，加
LIMIT并配合WHERE ctid > ?游标，避免长事务锁表
清理逻辑该放在哪一层？应用层还是数据库层？
答案取决于一致性要求和运维能力。
- 数据库层（触发器 / 存储过程）：能保证强一致性，但调试难、影响主库性能、部分云数据库不支持自定义触发器
- 应用层（代码中显式调用两次
DELETE）：可控、可观测、可重试，但需处理分布式事务边界（比如父表删成功、子表删失败时的状态补偿） - 折中方案：在应用删除父表后，异步投递消息到队列，由独立消费者执行子表清理——既解耦，又避免阻塞主流程
真正容易被忽略的是时间窗口：从父表行删除到子表清理完成之间，存在短暂的数据不一致期。如果业务对「子表必须严格依附父表」有强要求，这个窗口就得纳入监控和告警范围。
