安全删除需防隐性失效：必须显式加WHERE条件，子查询需非空且过滤NULL，MySQL同表操作需派生表或JOIN，PostgreSQL推荐WITH，IN易受NULL影响应改用EXISTS，大表须分批加索引。
不加 WHERE 条件的子查询删除会清空整张表，这是最常踩的坑；MySQL 禁止直接在子查询里引用目标表，PostgreSQL 对 IN 子查询返回列数有严格限制——安全删除不是写对语法就行，而是每一步都得防住隐性失效。
子查询删除必须显式加 WHERE 条件
哪怕子查询本身带条件，外层 DELETE 也必须有 WHERE。漏掉就等于 DELETE FROM table，整表数据瞬间消失。
- 常见翻车场景：
DELETE FROM orders WHERE id IN (SELECT order_id FROM logs WHERE status = 'timeout')看似合理，但如果logs表里没有匹配记录，IN (NULL)判定结果为UNKNOWN，实际删 0 行——你以为删了，其实没动 - 务必先单独执行子查询：
SELECT order_id FROM logs WHERE status = 'timeout'，确认返回非空、非NULL的有效 ID 列表 - 若子查询字段可能为
NULL（比如外键字段未设NOT NULL），必须加IS NOT NULL过滤：SELECT order_id FROM logs WHERE status = 'timeout' AND order_id IS NOT NULL
MySQL 中避免 “同一张表既查又删” 报错
DELETE FROM user WHERE id IN (SELECT id FROM user WHERE status = 'invalid') 在 MySQL 5.7+ 直接报错：You can't specify target table 'user' for update in FROM clause。
- 绕过方法：用派生表包装子查询，加别名：
DELETE FROM user WHERE id IN (SELECT id FROM (SELECT id FROM user WHERE status = 'invalid') AS tmp) - 更推荐用
JOIN写法，语义清晰且性能通常更好：DELETE u FROM user u INNER JOIN user u2 ON u.id = u2.id WHERE u2.status = 'invalid'，注意DELETE u必须指定别名 - PostgreSQL 不限制同表引用，但依然建议用
WITH提前定义子集，避免重复计算：WITH to_delete AS (SELECT id FROM user WHERE status = 'invalid') DELETE FROM user WHERE id IN (SELECT id FROM to_delete)
IN vs EXISTS：跨数据库兼容且防 NULL 失效
IN 遇到子查询返回 NULL 就整体失效；EXISTS 是相关子查询，天然绑定主表行，语义更稳。
- 错误写法：
DELETE FROM orders WHERE customer_id NOT IN (SELECT id FROM customers)—— 只要customers.id里有任意NULL，整个条件判为FALSE，一行不删 - 正确写法：
DELETE FROM orders WHERE NOT EXISTS (SELECT 1 FROM customers WHERE customers.id = orders.customer_id)，SELECT 1比SELECT *轻量，关联条件customers.id = orders.customer_id必须存在 - 执行前一定先
SELECT * FROM orders WHERE NOT EXISTS (...)预查，确认结果集符合预期
大表删除必须分批 + 加索引
一次性删几万行 ID，极易触发锁表、事务日志暴涨或 Lock wait timeout exceeded 错误，尤其在 InnoDB 中。
- 分批删：应用层控制循环，每次只删固定行数，例如：
DELETE FROM orders WHERE id IN (SELECT id FROM logs WHERE status = 'timeout' LIMIT 1000)，再重复执行直到子查询无返回 - 给子查询中用于过滤的字段建索引，比如
logs(status)或logs(status, order_id)，避免全表扫描 - 生产环境执行前，先跑
SELECT COUNT(*)估算待删量；超过 5 万行，优先考虑归档后TRUNCATE，而非硬删
真正难的不是写出能跑的 SQL，而是预判子查询在 NULL、空集、锁竞争、索引缺失这些边界情况下的真实行为。每次执行前多一句 SELECT 验证，比事后恢复快十倍。
