写SQL时不少人遇到过这种情况：明明在子查询里用了带索引的字段做过滤，可数据库仍然把外层表从头到尾读了一遍。要弄明白为什么，得先看清优化器是怎么把嵌套查询拆开执行的。
一、子查询的两种基本形态
在关系型数据库里，子查询通常分为非相关子查询和相关子查询。非相关子查询不依赖外层行的数据，执行一次即可；相关子查询则引用了外层表的列，理论上要对外层每一行都算一遍。优化器会尝试把相关子查询重写成半连接（semi join）或反连接（anti join），但很多写法会阻碍这一转换。
例如下面这段相关子查询，对orders表的每一行，都要去subquery里用customer_id匹配一次。如果优化器没做半连接改写，就会形成嵌套循环，外层全表扫描不可避免。
-- 相关子查询示例
SELECT o.id, o.amount
FROM orders o
WHERE o.customer_id IN (
SELECT c.id
FROM customers c
WHERE c.level = 'VIP'
AND c.region = o.region
);
非相关子查询虽然只执行一次，但若结果集很大且参与外层过滤，数据库可能选择先物化再关联，物化过程若无法利用索引也会触发扫描。理解这两种形态，是分析全表扫描成因的前提。
二、为什么优化器会放弃索引走全表扫描
核心原因在于“谓词无法下推”与“嵌套循环无法解关联”。当子查询中包含聚合、去重、或对外层列的引用被包裹在表达式里，优化器往往不能把外层条件推到内层表里使用索引。此时它只能把外层当驱动表，逐行去内层校验。
我们对比一个常见错误写法与改写写法。下面语句中，子查询里用了COUNT，导致无法转成半连接：
-- 容易全表扫描的写法
SELECT u.id
FROM users u
WHERE (
SELECT COUNT(*)
FROM logs l
WHERE l.user_id = u.id
) > 10;
这种写法让优化器对users每一行都执行一次子查询统计，logs表即使有user_id索引，也可能因计数需全量匹配而低效。改用JOIN与GROUP BY后，多数数据库能生成更优的哈希连接计划：
-- 改写后利用分组关联
SELECT u.id
FROM users u
JOIN (
SELECT user_id
FROM logs
GROUP BY user_id
HAVING COUNT(*) > 10
) t ON t.user_id = u.id;
从执行原理看，后者先把logs聚合物化成一个小表，再与users做等值连接，索引与统计信息都能被正常利用，避免了外层驱动时的盲目扫描。
三、通过执行计划验证扫描行为
不同数据库都提供查看执行计划的命令。以MySQL为例，在语句前加EXPLAIN就能看到type列是否为ALL（全表扫描），以及Extra里是否出现“Dependent Subquery”字样，后者明确提示了相关子查询未被优化。
EXPLAIN
SELECT o.id
FROM orders o
WHERE o.customer_id IN (
SELECT c.id
FROM customers c
WHERE c.level = 'VIP'
);
如果看到内层select_type为DEPENDENT SUBQUERY，说明优化器没做解关联。此时应检查子查询是否引用了外层列、是否包含不支持下推的函数。将子查询改写为JOIN或利用派生表，常能让type变为ref或eq_ref。
在PostgreSQL里则可使用EXPLAIN ANALYZE观察实际行数与预估差异。若嵌套循环的子节点总是扫描全表，就印证了上述原理。掌握这些工具，才能在调优时有的放矢。
四、常见优化思路与落地建议
第一，优先用EXISTS替代IN子查询。当子查询逻辑是“存在即满足条件”时，EXISTS更易被优化器转成半连接，且遇到第一条匹配就会停止，不必物化整个结果集。
-- 使用EXISTS改写
SELECT o.id, o.amount
FROM orders o
WHERE EXISTS (
SELECT 1
FROM customers c
WHERE c.id = o.customer_id
AND c.level = 'VIP'
);
第二，对频繁用于子查询关联的列建立联合索引。比如customers的(level, id)或logs的(user_id)都能显著减少内层探测成本。第三，在报表类重查询中，可先把子查询结果为临时表并建索引，再去做关联，把不可下推的计算显式拆开。
最后要注意，某些ORM框架自动生成的嵌套查询常带多余包装，应在数据访问层手动改写或采用CTE（公用表表达式）提升可读性兼优化机会。理清嵌套查询的执行原理，写SQL时就能主动避开全表扫描暗坑。