写SQL的时候，EXISTS和NOT EXISTS几乎是绕不开的两个关键字。很多开发者会下意识地认为它们只是简单的对立关系，效率应该差不多。但在SQLite的实际执行中，两者的表现可能相差几倍甚至几十倍，尤其是子查询表的数据量变大之后。这篇文章结合SQLite查询计划器的具体行为，拆解这两类子查询的执行过程，并给出可以直接落地的优化方案。
一、EXISTS与NOT EXISTS的执行原理差异
先看一个典型场景。假设有两张表：orders（订单表）和 customers（客户表），我们想知道哪些客户有订单、哪些客户没有订单。
-- 查询有订单的客户
SELECT name FROM customers c
WHERE EXISTS (
SELECT 1 FROM orders o WHERE o.customer_id = c.id
);
-- 查询没有订单的客户
SELECT name FROM customers c
WHERE NOT EXISTS (
SELECT 1 FROM orders o WHERE o.customer_id = c.id
);EXISTS的核心特性是短路求值。SQLite对外层每一行执行子查询时，只要在orders表中找到一条满足customer_id = c.id的记录，就会立即停止扫描并返回true，后面的数据看都不看。这意味着如果某个客户有上千条订单，EXISTS也只需要读取第一条就结束。
NOT EXISTS则完全相反。它必须确认子查询中不存在任何匹配记录，才能返回true。换句话说，子查询要把所有可能匹配的记录都检查一遍。如果customer_id列上没有索引，这个检查就是全表扫描；有索引的情况下，虽然能快速定位到目标区间，但仍然需要确认区间内一条记录都没有。
这种逻辑上的不对称，正是两者效率差异的根源。在数据分布均匀、索引完善的前提下，两者差距不大；可一旦索引缺失或者数据倾斜严重，NOT EXISTS的代价会被急剧放大。
二、用EXPLAIN QUERY PLAN看清真实执行计划
猜测性能是没有意义的，SQLite提供了EXPLAIN QUERY PLAN命令，可以直接看到查询计划器如何处理子查询。以上面的NOT EXISTS查询为例：
EXPLAIN QUERY PLAN
SELECT name FROM customers c
WHERE NOT EXISTS (
SELECT 1 FROM orders o WHERE o.customer_id = c.id
);如果orders.customer_id上有索引，输出大致会是这样：
QUERY PLAN |--SCAN c `--SEARCH o USING INDEX idx_orders_customer (customer_id=?)
这里的关键是SEARCH和SCAN的区别。SEARCH表示通过索引精确定位，SCAN表示全表扫描。如果你看到的计划里子查询部分是SCAN o而不是SEARCH o USING INDEX，那就说明关联列上没有索引，这时候NOT EXISTS的每一行外层记录都要触发一次全表扫描，性能会非常糟糕。
还有一个值得注意的细节：SQLite在较新版本中会对相关子查询做一些优化，比如把NOT EXISTS改写为反连接（anti-join）。但这种改写能否生效，仍然依赖于索引的存在。养成先跑一遍EXPLAIN QUERY PLAN的习惯，能帮你在写完SQL的几秒钟内就发现潜在的性能坑。
三、EXISTS、IN、LEFT JOIN三种写法怎么选
实现同一个需求通常有多种写法，比较常见的是用IN或者LEFT JOIN加NULL判断来替代EXISTS。下面三种写法逻辑等价：
-- 写法一：EXISTS
SELECT name FROM customers c
WHERE EXISTS (
SELECT 1 FROM orders o WHERE o.customer_id = c.id
);
-- 写法二：IN
SELECT name FROM customers c
WHERE c.id IN (SELECT customer_id FROM orders);
-- 写法三：LEFT JOIN
SELECT c.name FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NOT NULL;在SQLite中，EXISTS和IN的表现通常非常接近，新版查询计划器甚至会把两者优化成相似的执行计划。不过两者有一个细微区别：IN的子查询理论上会先取出完整的结果集（尽管SQLite会做物化或展开优化），而EXISTS从语义上就明确表达了一行匹配即可返回，优化器更容易利用短路逻辑。
LEFT JOIN的写法要格外小心。当orders表中一个客户对应多条记录时，LEFT JOIN会产生重复行，要么加DISTINCT要么改用分组，这两者都会带来额外的排序或去重开销。所以在判断存在性的场景下，LEFT JOIN通常不是首选。
至于NOT EXISTS的替代方案，可以用NOT IN，但要特别注意一个经典陷阱：如果子查询返回的结果集中包含NULL，NOT IN的整个条件会直接失效，查询结果为空集。这是一个非常隐蔽的bug来源，而NOT EXISTS不受NULL影响，语义更安全。
四、让子查询跑得更快的实战优化技巧
除了选对写法，还有一些具体手段可以显著提升子查询效率。最重要的一条就是给关联列建索引：
-- 给子查询的关联列建立索引 CREATE INDEX idx_orders_customer ON orders(customer_id); -- 复合索引也可以，把关联列放在合适的位置 CREATE INDEX idx_orders_customer_status ON orders(customer_id, status);
索引建好之后，EXISTS和NOT EXISTS的子查询都会从全表扫描变成索引查找，这通常是收益最大的一步优化。需要注意的是，如果子查询里还有其他过滤条件，比如WHERE o.customer_id = c.id AND o.status = 1，那么复合索引的列顺序会影响命中效果，把等值条件列都放进索引能获得最好的过滤性。
第二个技巧是控制外层查询的数据量。相关子查询的执行次数等于外层结果集的行数，如果外层表有十万行，子查询就要执行十万次。先通过WHERE条件把外层范围缩小，或者用CTE先把有订单的客户ID集合提取出来再做半连接，都能减少子查询的触发次数。
第三个技巧是利用ANALYZE更新统计信息。SQLite的查询计划器依赖表统计信息来选择连接顺序和索引，执行ANALYZE命令后，优化器能做出更准确的决策，特别是在多表关联、子查询嵌套的复杂语句中，效果往往比较明显。
ANALYZE; -- 更新所有表的统计信息
最后提一点：SELECT 1和SELECT *在EXISTS子查询中性能没有区别，因为EXISTS只关心有没有行返回，不读取具体列的内容。但如果子查询里写了SELECT * FROM orders，从可读性角度还是建议改成SELECT 1，明确表达意图，也避免误导后续维护的人以为需要读取列数据。
总结
EXISTS和NOT EXISTS的效率差异，本质上来自短路求值和全量确认两种不同逻辑，而真正决定性能上限的是索引设计和查询计划的选择。实践中记住三点：关联列必须建索引，写完SQL用EXPLAIN QUERY PLAN验证执行计划，判断不存在时优先用NOT EXISTS而不是NOT IN以避开NULL陷阱。做到这三点，子查询的性能问题基本可以规避掉大部分。