exists在delete中需用相关子查询关联外层表字段，如delete from orders where not exists (select 1 from customers c where c.id = orders.customer_id)；错误写法因缺失关联导致全删或不删；not exists不受子查询null影响，比not in更可靠；分批删除时须适配各数据库语法，且注意索引与锁。
EXISTS 在 DELETE 中的正确写法
直接用 EXISTS 做反向删除（删主表中“在从表不存在对应记录”的行）是可行的，但必须配合相关子查询，不能写成独立条件。常见错误是把 EXISTS 当成普通布尔表达式放在 WHERE 里却没关联外层表，结果删掉整张表或删错。
核心原则：子查询里必须用外层表的字段做关联，否则 EXISTS 永远为真或永远为假。
-
DELETE FROM orders WHERE NOT EXISTS (SELECT 1 FROM customers c WHERE c.id = orders.customer_id)✅ 正确：orders.customer_id关联了外层 -
DELETE FROM orders WHERE NOT EXISTS (SELECT 1 FROM customers WHERE id > 100)❌ 错误：子查询不依赖orders，可能全删或不删
为什么比 LEFT JOIN + IS NULL 更快？
多数情况下，EXISTS 的执行计划能更快短路——只要子查询找到一行匹配就停，而 LEFT JOIN 往往要先完成全部连接再过滤 IS NULL，尤其当从表很大、但匹配率很低时，EXISTS 优势明显。
但前提是：从表的关联字段（如 customers.id）有索引。没索引时，两者都慢，且 EXISTS 可能因重复执行子查询反而更差。
- 检查执行计划：关注是否用了
Index Seek或Index Lookup，而不是Table Scan - 如果从表关联字段无索引，先建索引比换写法更有效
- PostgreSQL 和 SQL Server 对
EXISTS优化较好；MySQL 5.7 及以前版本对某些NOT EXISTS场景优化不足，建议升级或加提示
NOT EXISTS 容易忽略的 NULL 陷阱
当关联字段允许为 NULL 时，NOT EXISTS 行为符合预期（NULL 值会被正常纳入“不存在”逻辑），但很多人误以为它和 NOT IN 一样会因子查询含 NULL 而整个条件返回 UNKNOWN ——其实不会。NOT EXISTS 完全不受子查询中 NULL 值影响，这是它比 NOT IN 更可靠的关键原因。
-
NOT IN (SELECT customer_id FROM archived_orders)：若子查询返回任意NULL，整条WHERE判定为FALSE，不删任何行 -
NOT EXISTS (SELECT 1 FROM archived_orders a WHERE a.customer_id = orders.customer_id)：即使archived_orders.customer_id有NULL，也不影响外层每行的判断 - 所以删“未归档订单”这类场景，优先选
NOT EXISTS，别碰NOT IN
带 LIMIT 或分批删除时怎么加 EXISTS
某些数据库（如 MySQL）不支持在带 LIMIT 的 DELETE 中直接用 EXISTS 子查询（报错：This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'）。这时得绕一下：
DELETE o FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM customers c WHERE c.id = o.customer_id ) ORDER BY o.id LIMIT 1000;
注意语法差异：
- MySQL 必须用多表删除语法（
DELETE o FROM orders o），不能写DELETE FROM orders - PostgreSQL 不支持
LIMIT在DELETE里，得用CTE或子查询套一层 - SQL Server 用
TOP (1000)放在DELETE关键字后，不是WHERE后
分批删时，EXISTS 的性能波动小，但要注意事务粒度和锁范围——删太多行可能长时间锁住主表索引页，线上操作务必控制每次 LIMIT 数量，并避开高峰期。
