EXISTS 子查询在 DELETE 中常比 JOIN 慢，因可能反复执行、缺乏索引导致全表扫描，且优化器对 EXISTS 驱动表选择和物化策略不稳定；而 JOIN 更易触发哈希连接或索引嵌套循环，性能更优。
WHERE EXISTS 子查询在 DELETE 中 为什么 常比 JOIN 慢
多数情况下，DELETE FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id) 的执行效率低于等价的 JOIN 写法，尤其当 t2 数据量大、缺乏合适索引或子查询无法提前终止时。数据库优化器对 EXISTS 在 DELETE 场景下的驱动表选择和物化策略往往不如显式 JOIN 稳定。
常见错误现象：EXISTS 子查询被反复执行（每行 t1 都触发一次），而 t2 又没在关联字段上建索引，导致全表扫描 × t1 行数；或者优化器误判为“半连接”，未下推过滤条件。
- 确保
t2的关联列（如id）有索引，否则EXISTS几乎必然退化 - PostgreSQL 和 SQL Server 对
EXISTS删除优化较好，MySQL 5.7 及更早版本对EXISTS在DELETE中支持弱，8.0+ 改善但仍有例外 - 如果
t2是派生表或含复杂逻辑（如GROUP BY、窗口函数），EXISTS很可能被强制物化，而JOIN更容易复用中间结果
用 JOIN 重写 DELETE 的标准写法与注意事项
主流数据库都支持 DELETE t1 FROM t1 INNER JOIN t2 ON t1.id = t2.id 这类语法，语义清晰且优化器更容易选择哈希连接或索引嵌套循环。
使用场景：清理主表中在维度表 / 临时表 / 日志表中存在对应记录的行；多表关联删除（如级联但不依赖外键）。
- MySQL 必须写成
DELETE t1 FROM t1 JOIN t2 ON ……，不能省略别名t1，否则报错ERROR 1064 - PostgreSQL 不支持直接
DELETE …… USING的JOIN形式，要用USING子句：DELETE FROM t1 USING t2 WHERE t1.id = t2.id - SQL Server 支持
DELETE t1 FROM t1 INNER JOIN t2 ON ……，也支持FROM t1 INNER JOIN t2的变体，但推荐显式写INNER JOIN避免歧义 - 如果要加额外过滤（如只删
t2.status = 'invalid'），必须把条件放在ON或WHERE中——放在ON会影响连接结果集大小，放在WHERE是最终过滤，行为不同
性能差异的实际观测点
不要只看执行时间，重点观察执行计划中的几个关键信号：
-
Rows examined（MySQL）或Actual Rows（PostgreSQL/SQL Server）是否远大于预期删除行数——说明存在嵌套循环放大 - 是否存在
Materialize、Temp Table或Spool算子，尤其在EXISTS子查询里出现，基本意味着 性能瓶颈 - 连接类型是否为
Hash Join或Index Nested Loop；若降级为Block Nested Loop或多次Index Scan，说明统计信息不准或缺少索引 - 检查
t1是否被全表扫描：如果WHERE条件本可走索引，但用了EXISTS后优化器放弃索引，大概率是子查询干扰了访问路径选择
什么情况反而该坚持用 EXISTS
不是所有场景都适合强行改写为 JOIN。以下情况 EXISTS 更安全或更高效：
-
t2是一个带LIMIT 1或强过滤条件的子查询（如SELECT 1 FROM logs WHERE user_id = t1.id AND created_at > NOW() - INTERVAL 1 DAY LIMIT 1），此时EXISTS可短路，而JOIN会先生成全部匹配结果再删 - 需要语义上的“存在性判断”而非“精确匹配”，比如
t2有多条匹配记录，但只要有一条就删t1，用JOIN可能导致重复删除（虽然DELETE本身幂等，但连接放大后Rows examined暴涨） - 权限或视图限制导致无法直接
JOIN到目标表（例如t2是跨库视图，某些数据库不允许DELETE …… FROM …… JOIN view） - SQL 标准兼容要求高，且目标环境混合多种数据库（
EXISTS写法通用性更好）
真正影响性能的从来不是语法本身，而是优化器能否准确估算中间结果集大小、是否有可用索引、以及你有没有看过执行计划里那几行关键数字。别猜，EXPLAIN 一下再说。
