DELETE不能直接用JOIN，需用子查询或EXISTS；IN易受NULL影响，应加IS NOT NULL或改用EXISTS；CTE需配合主DELETE使用；删前必须验证子查询结果并加事务保护。
DELETE 中不能直接用 JOIN，得靠子查询套一层
MySQL 和 PostgreSQL 等主流数据库都不允许在 DELETE 语句里直接写 JOIN（除非是 MySQL 特殊语法 DELETE ... FROM ... JOIN，但可读性和兼容性差）。想根据另一张表的条件删数据，必须用子查询把目标主键或唯一标识先拎出来。
常见错误是写成：DELETE FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'inactive') —— 表面看没问题，但如果子查询返回 NULL，整个 IN 判断会失效（1 IN (1, NULL) 结果为 UNKNOWN，不匹配），导致删不掉任何记录。
- 务必加
WHERE ... IS NOT NULL过滤子查询结果，或改用EXISTS -
EXISTS更安全：它只关心是否存在匹配行，不受NULL影响 - 子查询里尽量只选主键字段，避免拖慢性能；如果涉及多表关联，注意别漏加
WHERE条件导致全表扫描
用 EXISTS 替代 IN 避免 NULL 陷阱
EXISTS 是更鲁棒的选择，尤其当子查询可能含 NULL 或需要关联多字段时。它的执行逻辑是“对外层每一行，检查子查询是否返回至少一行”，不依赖值比较，天然绕过 NULL 问题。
比如删掉所有没有订单的用户：
DELETE FROM users WHERE NOT EXISTS ( SELECT 1 FROM orders WHERE orders.user_id = users.id );
-
SELECT 1是惯用写法，比SELECT *轻量，数据库优化器也认得这种模式 - 子查询里的
orders.user_id = users.id必须写清楚关联条件，否则变成笛卡尔积，删错数据 - 如果
orders.user_id没建索引，这个NOT EXISTS可能非常慢——记得给外键字段加索引
PostgreSQL 和 SQL Server 的 WITH 子句删除法
PostgreSQL 和 SQL Server 支持 WITH（CTE）配合 DELETE，写法更清晰，还能复用中间结果。但注意：CTE 本身不支持直接删，必须把 CTE 当作子查询来驱动主 DELETE。
例如在 PostgreSQL 中删掉重复邮箱中保留 id 最小的那条以外的所有记录：
WITH duplicates AS ( SELECT email, MIN(id) AS keep_id FROM users GROUP BY email HAVING COUNT(*) > 1 ) DELETE FROM users WHERE email IN (SELECT email FROM duplicates) AND id NOT IN (SELECT keep_id FROM duplicates);
- CTE 不能直接跟在
DELETE后面（如DELETE FROM (WITH ...) t是错的） - 上面例子用了两次子查询，效率不如窗口函数方案；真正高效的做法是用
ROW_NUMBER()+ CTE 标记要删的行 - SQL Server 要求 CTE 前必须加分号（上一行语句结尾加分号），否则报错
Incorrect syntax near WITH
删前务必加 WHERE 条件并手动验证子查询
嵌套删除最危险的地方在于——你根本看不到要删哪些行，直到执行完才后悔。永远不要跳过验证步骤。
- 先把子查询单独跑一遍：
SELECT id FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'deleted')，确认数量和预期一致 - 如果删的是大表，加
LIMIT（MySQL/PostgreSQL）或TOP N（SQL Server）做分批删，避免锁表太久 - 生产环境建议用事务包住：
BEGIN; DELETE ...; SELECT ROW_COUNT(); ROLLBACK;（先看影响行数再决定是否COMMIT） - 某些数据库（如 MySQL 5.7+）对子查询中的目标表有严格限制：不能在子查询里引用正被删的表名，会报错
You can't specify target table for update in FROM clause—— 此时必须用派生表包装，比如(SELECT id FROM (SELECT id FROM users WHERE ...) AS tmp)
嵌套删除的复杂度不在语法，而在数据关系的隐蔽性。哪怕逻辑看起来简单，只要涉及多表、NULL、索引缺失或未加事务，就很容易误删或卡死。动手前花两分钟验证子查询结果，比事后恢复快十倍。
