EXISTS 比 IN 删除更快，因其采用半连接+短路机制，找到首匹配即停止；而 IN 需生成完整结果集并处理 NULL 导致逻辑异常与性能损耗。
EXISTS 为什么比 IN 删除更快？
当删除主表中被子查询匹配的记录时，EXISTS 通常比 IN 更快，核心原因是执行逻辑不同：IN 会先生成子查询的完整结果集（可能去重、可能含 NULL），再做哈希或循环匹配；而 EXISTS 是对主表每行执行一次**半连接（semi-join）**，只要子查询找到**第一个匹配行就短路返回 true**，不继续查。尤其在子查询结果集大、但匹配率低时，优势明显。
另外，IN 遇到子查询结果含 NULL 时，整个条件会变成 UNKNOWN，导致意外跳过删除（SQL 三值逻辑）；EXISTS 完全不受 NULL 影响。
DELETE ... EXISTS 的标准写法与常见错误
正确结构是：DELETE FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.col = t1.col)。关键点在于子查询必须**关联外层表**，否则变成非相关子查询，可能误删全表或性能更差。
- ❌ 错误：未关联 —
DELETE FROM orders WHERE EXISTS (SELECT 1 FROM customers WHERE status = 'inactive')→ 若子查询有结果，删掉所有 orders - ✅ 正确：显式关联 —
DELETE FROM orders WHERE EXISTS (SELECT 1 FROM customers WHERE customers.id = orders.customer_id AND customers.status = 'inactive') - ⚠️ 注意：子查询里用
SELECT 1就够了，不用SELECT *或具体字段，避免无谓列解析开销
IN 转 EXISTS 时要检查的三个兼容性陷阱
直接把 IN 子句换成 EXISTS 并不总是安全，需确认以下三点：
-
IN子查询是否包含NULL？若原始语句依赖IN对NULL的“失效”行为（比如WHERE id IN (1,2,NULL)实际等价于WHERE id IN (1,2)），换成EXISTS后逻辑会变，必须补上IS NOT NULL条件或重构逻辑 - 子查询是否有
DISTINCT或聚合？IN自动去重，EXISTS不需要也不关心重复，但若原IN依赖DISTINCT过滤逻辑（如排除重复关联），需在EXISTS的WHERE中复现该过滤 - 索引是否覆盖关联字段？
EXISTS性能极度依赖子查询中WHERE条件字段（尤其是关联列）是否有索引。例如customers.id = orders.customer_id要求customers(id)或customers(id, status)有合适索引
真实场景下的性能对比与验证方法
别只看执行计划里的“cost”，重点观察实际执行的 Rows Removed 和 Actual Total Time。用 EXPLAIN (ANALYZE, BUFFERS) 对比两个语句：
EXPLAIN (ANALYZE, BUFFERS) DELETE FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE status = 'inactive');
EXPLAIN (ANALYZE, BUFFERS) DELETE FROM orders WHERE EXISTS (SELECT 1 FROM customers WHERE customers.id = orders.customer_id AND customers.status = 'inactive');
如果子查询结果集大（比如几万行 inactive 客户），但每个订单只匹配一个客户，EXISTS 版本通常显示更少的“Shared Hit Blocks”和更低的“Execution Time”。但如果子查询本身慢（比如没走索引），换 EXISTS 也救不了 — 先优化子查询才是根本。
真正容易被忽略的是：EXISTS 在删除大量数据时，可能让事务膨胀更快（因为逐行判断 + 行锁粒度），若需删百万级，得结合分区或分批处理，不能只靠改写谓词。
