mysql支持delete join语法，但postgresql、sql server、sqlite等不支持，会直接报错；必须改用子查询in或exists，且需按外键依赖逆序删除以避免约束冲突。
为什么不能直接用 JOIN 写 DELETE？
MySQL 支持 DELETE ... JOIN 语法，但 PostgreSQL、SQL Server、SQLite 等主流数据库**根本不允许在 DELETE 语句中直接写 JOIN**。强行写会报错，比如 PostgreSQL 报 ERROR: syntax error at or near "JOIN"，SQL Server 报 Incorrect syntax near the keyword 'JOIN'。这不是写法不熟的问题，是语法层面禁止——因为级联删除涉及多表依赖和事务一致性，DBMS 要求你显式控制执行路径。
用子查询 + IN 实现安全级联 DELETE（兼容性最强）
这是跨数据库最稳妥的方式：先查出要删的主表 ID，再用这些 ID 去删子表，最后删主表。关键点在于必须按**外键依赖逆序**执行（先删子表，再删父表），否则会触发外键约束失败。
假设三张表：orders（主表）、order_items（外键指向 orders.id）、payments（外键也指向 orders.id）：
DELETE FROM order_items WHERE order_id IN ( SELECT id FROM orders WHERE status = 'cancelled' AND created_at
- 每个
DELETE都复用同一组条件，确保逻辑一致；手写两次SELECT比用 CTE 更兼容旧版本（如 MySQL 5.7 不支持 CTE） - 务必检查外键定义：
ON DELETE CASCADE虽能自动级联，但无法加条件过滤子表行——它要么全删，要么不删 - 如果子表数据量大，
IN (SELECT ...)在某些数据库（如老版本 MySQL）可能性能差，可改用EXISTS或分批处理
PostgreSQL / SQL Server 中用 CTE + WITH 做原子级条件级联
当需要“一次提交、全部成功或全部回滚”，且数据库支持 CTE（PostgreSQL、SQL Server、较新 MySQL/SQLite），可以用 WITH 先锁定符合条件的主键集，再在后续 DELETE 中复用：
WITH target_orders AS ( SELECT id FROM orders WHERE status = 'cancelled' AND created_at
- CTE 本身不保存结果，每次
SELECT都重执行，所以仍需确保三次 CTE 定义完全一致 - 不能把三个
DELETE合并在一个事务里就认为“原子”——CTE 只作用于单条语句，跨语句仍需显式BEGIN TRANSACTION/COMMIT - SQL Server 对 CTE 后接
DELETE要求必须有别名（DELETE o FROM order_items o...），否则报错
真正容易被忽略的陷阱：NULL 外键和批量性能
外键字段为 NULL 时，IN (SELECT ...) 自动跳过（因为 NULL IN (1,2,NULL) 结果为 UNKNOWN），这看似安全，但可能掩盖本该被清理的脏数据。更隐蔽的是性能问题：若 orders 表有千万级数据，而条件只命中几十行，但子表 order_items 没有 order_id 索引，DELETE 就会全表扫描。
- 执行前必查：子表外键列是否有索引？用
EXPLAIN看执行计划是否走了索引 - 生产环境禁用无 LIMIT 的大范围
DELETE；应拆成每批 1000–5000 行，用WHERE id BETWEEN ? AND ?或游标分页 - 如果业务允许，优先考虑软删除（加
is_deleted字段），避免锁表和日志暴涨
级联 DELETE 的复杂性不在语法，而在你是否清楚每张表的数据规模、索引状态、外键行为，以及事务边界的实际覆盖范围。
