EXISTS删除必须嵌套在DELETE的WHERE子句中，如DELETE FROM t1 WHERE EXISTS(SELECT 1 FROM t2 WHERE t2.ref = t1.id)；它比IN快因短路求值，且SELECT 1比SELECT *更安全高效。
EXISTS 删除比 IN 删除快，但必须配对 WHERE 条件
直接用 EXISTS 做删除本身不生效——它只是子查询判断逻辑，必须嵌套在 DELETE 的 WHERE 子句里。常见错误是写成 DELETE FROM t1 EXISTS (SELECT ...)，这语法根本通不过。正确结构永远是：DELETE FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.ref = t1.id)。
为什么快？因为 EXISTS 找到第一条匹配就短路返回 TRUE，而 IN 可能要生成完整结果集再做哈希或遍历，尤其当子查询返回 NULL 或大量重复值时，IN 还可能意外跳过整行（SQL 标准中 NULL IN (..., NULL, ...) 结果为 UNKNOWN，不满足 WHERE 条件）。
子查询里 SELECT 后面写什么不重要，但别写 *
EXISTS 只关心子查询是否能返回至少一行，不关心具体字段内容。所以 SELECT * 不但多余，还可能触发不必要的列解析或权限检查（比如某些数据库对 * 隐式展开后发现用户无某列权限，报错）。更糟的是，如果子查询里用了聚合或窗口函数，* 可能导致语法错误或计划异常。
统一写 SELECT 1 或 SELECT NULL 最稳妥：
DELETE FROM orders WHERE EXISTS ( SELECT 1 FROM customers c WHERE c.id = orders.customer_id AND c.status = 'inactive' );
关联字段没索引？EXISTS 删除会慢得像全表扫描
外表（被删表）的关联字段和子查询内表的过滤字段，都建议建索引。例如上例中，orders.customer_id 和 customers.id 都要有索引；如果子查询还有 c.status = 'inactive'，最好建联合索引 INDEX idx_status_id (status, id)。
没索引时，数据库大概率对子查询每次执行都扫一遍 customers 表——外表删 10 万行，子查询就执行 10 万次全表扫描。
- PostgreSQL 会倾向用
Hash Semi Join，但前提是子查询结果集小且可物化；否则退化为 Nested Loop - MySQL 8.0+ 对
EXISTS优化较好，但依然依赖索引；5.7 及之前版本遇到复杂子查询容易误选执行计划 - SQL Server 在子查询含
TOP 1时可能改写为更优计划，但纯EXISTS仍吃索引
DELETE ... EXISTS 不能加 LIMIT，想限删数量得换思路
标准 SQL 中，DELETE 语句不允许在 EXISTS 子句后接 LIMIT 或 TOP（MySQL/PostgreSQL 支持 LIMIT，但它是作用于整个 DELETE，不是子查询）。如果你只想删最多 100 行匹配数据，不能靠子查询控制，得靠外层限制：
-- MySQL 写法 DELETE FROM orders WHERE EXISTS ( SELECT 1 FROM customers c WHERE c.id = orders.customer_id AND c.status = 'inactive' ) LIMIT 100;
但要注意：这个 LIMIT 是随机的 100 行（无 ORDER BY 时），且不同数据库行为不一致。PostgreSQL 必须用 CTE + ROW_NUMBER() 或 USING 临时表；SQL Server 要用 TOP (100) 放在 DELETE 关键字后。真正需要确定顺序时，别依赖 EXISTS 本身——先查出 ID 列表，再按需删。
最易被忽略的一点：事务中批量删大表时，EXISTS 子查询若涉及未提交的其他事务数据，可能因隔离级别产生不可预期的阻塞或幻读，尤其在 READ COMMITTED 下反复执行子查询时。这时候不如先用 SELECT FOR UPDATE 锁定再删。
