exists删除更快是因为其短路机制：找到首个匹配即退出，不物化结果集、不处理null陷阱、避免全表扫描与去重；而in需完整执行子查询并去重，遇null则条件失效，且依赖索引有效性。
EXISTS 为什么比 IN 删除更快
当删除语句涉及子查询且主表数据量大时，IN 容易触发全表扫描 + 去重 + 隐式转换，而 EXISTS 只需判断是否存在匹配行，找到第一个就短路退出。尤其在子查询结果集大、但匹配率低的场景下，性能差距可能达数倍。
DELETE ... EXISTS 的标准写法
注意：必须用相关子查询（correlated subquery），即子查询中引用主表别名；否则 EXISTS 会恒为真或恒为假，导致误删。
正确示例：
DELETE FROM orders o WHERE EXISTS ( SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'inactive' );
常见错误写法（无关联）：
-- ❌ 错误：子查询不依赖 o，逻辑失效 DELETE FROM orders WHERE EXISTS (SELECT 1 FROM customers WHERE status = 'inactive');
-
EXISTS子查询里必须包含对主表字段的引用（如c.id = o.customer_id） - 子查询中
SELECT后面的内容无关紧要，SELECT 1或SELECT NULL均可 - 避免在
EXISTS子查询中使用SELECT *，虽不报错但语义冗余
IN 和 EXISTS 在 NULL 处理上的关键差异
如果子查询返回 NULL，IN 会整体返回 UNKNOWN，导致该行不被删除；而 EXISTS 不受 NULL 影响——只要存在任意一行匹配（非 NULL 判断），就返回 TRUE。
典型陷阱：
-- 假设 customers.id 允许 NULL SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers); -- 若子查询返回 NULL，则整条 IN 条件失效，可能漏删
- 当
customer_id字段可能为NULL，且子查询列允许NULL时，IN行为不可靠 -
EXISTS更安全，因为它只关心「是否有行满足关联条件」，不比较值本身 - 若业务上需排除
NULL关联，应在EXISTS子查询中显式加AND c.id IS NOT NULL
索引是否生效？看关联字段有没有走索引
EXISTS 性能优势的前提是子查询中的关联字段有索引。否则它仍会扫描整个子表。
- 确保子查询里的等值条件字段（如
c.id）在子表上有索引 - 若关联条件含多个字段（如
c.id = o.customer_id AND c.region = 'US'），考虑联合索引顺序：(region, id)或(id, region)，取决于过滤选择性 - 执行前务必用
EXPLAIN看是否用了type=ref或type=index_subquery，而非ALL
真正卡住性能的往往不是 IN 还是 EXISTS，而是没索引的关联字段——这点比语法切换更重要。
