标量子查询消除：数据库优化器的一场“等价变戏法”

在数据库性能调优的日常工作中，有一种SQL写法总是让DBA又爱又恨------标量子查询。

爱它，是因为它写起来太顺手了。你只需要在一个括号里放一个返回单值的子查询，就能在主查询的SELECT列表里优雅地挂上一个"计算列"。逻辑清晰，语义直接，不需要考虑JOIN会不会导致数据膨胀，不需要担心GROUP BY的细节。业务开发人员尤其喜欢这种写法，因为它能用最少的代码表达最复杂的业务逻辑。

恨它，是因为它在执行计划里往往扮演着"性能刺客"的角色。外表返回一千行，标量子查询就可能被触发一千次。相关子查询更是如此------每一次触发都带着一个新的参数，缓存失效，索引虽然能帮上忙，但累积的开销足以让一个简单的报表查询从秒级退化到分钟级。

我一直认为，评价一个数据库优化器是否"聪明"，有一个很直观的指标：它能不能自动消除标量子查询。这不是一个噱头功能，而是一场对数据库内核等价变换能力的实战检验。

这篇文章，我想系统地聊聊标量子查询消除这件事。先分析它为什么难做，然后介绍金仓数据库在V009R002C014版本中引入的消除机制------从等价性判定、到连接转换、再到相似子查询合并。全程会配合代码示例和执行计划的分析，希望能给正在研究数据库内核或者被标量子查询折磨的开发者一些启发。

一、先从一个"看起来很对"的SQL说起

假设我们有两张表：一张是订单主表orders，一张是订单明细表order_items。

sql 复制代码

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    order_date DATE,
    customer_id INT
);

CREATE TABLE order_items (
    item_id INT PRIMARY KEY,
    order_id INT,
    product_id INT,
    quantity INT,
    price DECIMAL(10,2)
);

现在，业务上需要一张报表：列出最近一个月的订单，并附带每个订单的总金额、商品种类数和平均单价。

一个很自然的写法是：

sql 复制代码

SELECT o.order_id,
       o.order_date,
       (SELECT SUM(quantity * price) 
        FROM order_items oi 
        WHERE oi.order_id = o.order_id) AS total_amount,
       (SELECT COUNT(*) 
        FROM order_items oi 
        WHERE oi.order_id = o.order_id) AS item_count,
       (SELECT AVG(price) 
        FROM order_items oi 
        WHERE oi.order_id = o.order_id) AS avg_price
FROM orders o
WHERE o.order_date >= CURRENT_DATE - INTERVAL '30 days';

如果用手工执行计划的方式来推演这个SQL的执行过程，大概是这样：

对orders表做全表扫描（或者索引扫描），找到符合条件的订单行。假设有N行。
对于每一行，执行第一个标量子查询：对order_items做一次扫描（或者索引查找），计算SUM。
对于同一行，再执行第二个标量子查询：对order_items再做一次扫描，计算COUNT。
对于同一行，再执行第三个标量子查询：对order_items再做一次扫描，计算AVG。

所以，最终对order_items的扫描次数是 3 × N。如果N=10000，那就是30000次扫描。即使order_items在order_id上有索引，30000次索引查找的开销依然惊人------每次查找都要经历B+树的根到叶子节点的遍历，加上CPU的累加计算。

我在测试环境里用10000行订单、每个订单平均5条明细的数据量跑了一下这个SQL（关闭了标量子查询消除功能），耗时大约28秒。对于一个报表接口来说，这个响应时间是不可接受的。

也许你会说，这是开发者的问题，他们不应该这样写SQL。但现实是，在复杂的业务系统中，这种写法比比皆是。一个大型ERP系统的某个统计模块，可能有几十个标量子查询嵌套在SELECT和WHERE子句中。如果要求每个开发人员都熟练掌握子查询到JOIN的手工改写技巧，既不现实，也不合理。

二、手工改写能解决问题，但不优雅

面对上面的性能问题，一个有经验的DBA会立刻想到一种改写方式：把标量子查询提升为内联视图，然后左外连接。

sql 复制代码

SELECT o.order_id,
       o.order_date,
       COALESCE(agg.total_amount, 0) AS total_amount,
       COALESCE(agg.item_count, 0) AS item_count,
       agg.avg_price
FROM orders o
LEFT JOIN (
    SELECT order_id,
           SUM(quantity * price) AS total_amount,
           COUNT(*) AS item_count,
           AVG(price) AS avg_price
    FROM order_items
    GROUP BY order_id
) agg ON o.order_id = agg.order_id
WHERE o.order_date >= CURRENT_DATE - INTERVAL '30 days';

这个改写版本的执行计划会变成：先扫描order_items一次，做GROUP BY聚合，产生一个以order_id为键的中间结果集，然后和orders表做哈希连接（或嵌套循环连接，取决于数据分布）。order_items只被扫描了一次，三种聚合值一次计算完成。在我的测试环境里，这个改写版本的执行时间从28秒降到了0.3秒。

看起来问题解决了。但手工改写有几个绕不开的痛点：

第一个痛点：语义正确性需要人工保证。 原始标量子查询在order_items没有匹配数据时，SUM返回NULL，COUNT返回0。在改写版本里，agg.total_amount在没有匹配时会变成NULL，而agg.item_count在没有匹配时也是NULL------但COUNT原本应该返回0。所以需要给total_amount和item_count分别加上COALESCE(..., 0)，给avg_price加COALESCE(..., NULL)（其实可以不加）。这种细微的差别很容易被忽略，导致改写后的结果与原SQL不一致。

第二个痛点：代码膨胀。 如果SELECT后面挂了5个标量子查询，手工改写后的SQL长度会翻倍。更麻烦的是，如果原始SQL中还有WHERE条件里嵌套了标量子查询，改写难度会指数级上升。

第三个痛点：维护成本。 原始SQL的业务逻辑是用标量子查询表达的，这通常是业务开发人员直接写出来的。而改写后的SQL是DBA或资深开发人员为了性能优化的产物。当业务逻辑发生变化时（比如增加一个新的聚合维度），需要同时维护两份SQL，或者让所有人都按照改写风格来写。实际上，在绝大多数开发团队里，这个要求是不现实的。

所以，更合理的选择是：让数据库优化器来自动完成这个改写。这就要求优化器能够在保证语义等价的前提下，识别出可以消除的标量子查询，并选择最优的消除方式（包括合并相似的子查询）。

三、优化器面临的四道关卡

自动消除标量子查询，听起来很简单------不就是把(SELECT ... FROM t2 WHERE t2.id = t1.id)变成LEFT JOIN (SELECT ... FROM t2 GROUP BY id) ON ...吗？但真正在优化器内核里实现这个功能，需要跨越四道关卡。

3.1 关卡一：如何保证"最多返回一行"

标量子查询的语义约束是：最多返回一行。如果子查询实际返回了多行，数据库运行时应该报错（例如Oracle的ORA-01427）。这个运行时错误是SQL语义的一部分。

把标量子查询改写成LEFT JOIN + GROUP BY之后，GROUP BY天然保证了聚合后的结果集在每个分组键下只有一行，所以"返回多行"的情况不会发生。但是，原始子查询如果包含GROUP BY但分组键不是唯一的，那它本身可能返回多行------这种情况下，原始SQL是会报错的。如果优化器强行消除，就会把一个会报错的SQL变成一个可以正常执行但结果错误的SQL，这显然是不允许的。

因此，优化器在做消除之前，必须证明子查询在原始语义下"最多只返回一行"。通常的做法是检查以下几种情况：

子查询的顶层包含了聚合函数（SUM/COUNT/AVG/MAX/MIN），且没有显式的GROUP BY。聚合函数在不带GROUP BY时保证返回一行。
子查询显式写了GROUP BY，且分组键是某个唯一键（比如主键或唯一索引）。
子查询的WHERE条件直接限定了某个唯一键等于常量（这种情况下返回一行或零行）。
子查询中使用了FETCH FIRST 1 ROW ONLY或LIMIT 1（虽然这种写法在标量子查询中不常见）。

如果上述条件都不满足，优化器应当保守地放弃消除，避免改变语义。

3.2 关卡二：COUNT和SUM的"空值陷阱"

这是一个非常容易被忽视的细节。看下面两条SQL：

sql 复制代码

-- 原始SQL，使用标量子查询
SELECT id,
       (SELECT COUNT(*) FROM t2 WHERE t2.ref_id = t1.id) AS cnt,
       (SELECT SUM(amount) FROM t2 WHERE t2.ref_id = t1.id) AS sum_amt
FROM t1;

假设t1中有一条记录，在t2中没有匹配的ref_id。那么原始SQL的执行结果：cnt=0，sum_amt=NULL。

现在看一个朴素的"消除"改写：

sql 复制代码

SELECT t1.id,
       COALESCE(agg.cnt, 0) AS cnt,
       agg.sum_amt
FROM t1
LEFT JOIN (
    SELECT ref_id, COUNT(*) AS cnt, SUM(amount) AS sum_amt
    FROM t2
    GROUP BY ref_id
) agg ON t1.id = agg.ref_id;

当没有匹配时，agg.cnt和agg.sum_amt都是NULL。经过COALESCE(agg.cnt, 0)处理，cnt变成了0，符合预期；而agg.sum_amt保持了NULL，也符合预期。似乎没问题。

但如果原始子查询中混合使用了COUNT和SUM，而优化器在消除时没有对COUNT做特殊处理------比如直接让agg.cnt传递到外层而没有COALESCE------那么没有匹配时cnt就会变成NULL，和原始语义不符。所以优化器在生成改写后的表达式时，需要根据聚合函数的类型来决定是否插入默认值处理。对于COUNT，缺省值应该是0；对于SUM/AVG/MAX/MIN，缺省值应该是NULL。

这个问题在不同的数据库中有不同的处理方式。有些数据库选择在子查询消除阶段不处理COUNT的特殊性，而是依赖执行器在运行时对NULL进行转换。但这种做法会增加执行时的判断开销。金仓的做法是在等价性判定阶段就记录每个聚合函数的类型，并在生成外连接的结果列时，为COUNT表达式自动包裹一个COALESCE(..., 0)。

3.3 关卡三：如何处理"相似但不完全相同"的多个子查询

前面例子中，三个标量子查询的结构完全一样，只是聚合函数不同。这种情况很容易合并。但现实中的SQL往往更复杂。

考虑这样一个场景：

sql 复制代码

SELECT o.order_id,
       (SELECT SUM(amount) FROM order_items oi WHERE oi.order_id = o.order_id) AS total_amount,
       (SELECT SUM(amount) FROM order_items oi WHERE oi.order_id = o.order_id AND oi.status = 'PAID') AS paid_amount
FROM orders o;

两个子查询都访问order_items，关联条件相同（order_id），但第二个子查询多了一个过滤条件status='PAID'。这种情况下还能合并吗？

可以，但合并后的内联视图需要能够同时提供总金额和已付金额。一种方式是使用条件聚合：

sql 复制代码

SELECT o.order_id,
       COALESCE(agg.total_amount, 0) AS total_amount,
       COALESCE(agg.paid_amount, 0) AS paid_amount
FROM orders o
LEFT JOIN (
    SELECT order_id,
           SUM(amount) AS total_amount,
           SUM(CASE WHEN status = 'PAID' THEN amount ELSE 0 END) AS paid_amount
    FROM order_items
    GROUP BY order_id
) agg ON o.order_id = agg.order_id;

这就要求优化器能够识别出两个子查询的基础表相同、关联条件相同，但额外谓词不同，然后通过生成CASE WHEN表达式来合并。这在优化器中属于"聚合下推"和"谓词推导"的组合技术，实现起来比简单合并复杂得多。

金仓的当前版本主要处理的是聚合函数不同、但WHERE条件完全相同的场景。对于谓词存在差异的情况，属于更高级的合并策略，可能在后续版本中增强。

3.4 关卡四：相关子查询的解关联

标量子查询的"相关性"------即内层引用了外层的列------是导致重复执行的根源。消除的本质就是解关联。解关联的一般性方法是：将相关子查询转换成等价的GROUP BY + JOIN形式，使得内层查询不再依赖外层每一行的具体值，而是一次性计算出所有可能的值，然后通过连接操作来匹配。

解关联的技术在数据库领域已经研究了很多年。从早期的"子查询上拉"（Subquery Flattening）到后来的"解嵌套"（Unnesting），再到基于"魔集"（Magic Set）的改写，每种方法都有其适用场景。

对于标量子查询这种特殊形式，解关联相对简单：只需要把子查询中的相关条件（WHERE oi.order_id = o.order_id）提取出来，作为GROUP BY的键和JOIN的条件。

但需要注意的是，原始的子查询可能不是简单的SELECT AGG FROM T WHERE T.key = outer.key，而可能包含更复杂的表达式，比如：

sql 复制代码

(SELECT SUM(amount) FROM order_items oi WHERE ABS(oi.order_id) = o.order_id)

这里的相关条件是ABS(oi.order_id) = o.order_id。这种条件下，不能简单地把oi.order_id作为GROUP BY的键，因为外层传入的值和内层的原始列之间存在函数变换。解关联后，JOIN条件应该是ABS(oi.order_id) = agg.order_id吗？但内联视图的GROUP BY键是oi.order_id（或者需要是ABS(oi.order_id)？）这会导致复杂的等价推理。

金仓的优化器在处理这类复杂相关条件时采取保守策略：如果相关条件不是简单的等值条件（即内层列 = 外层列或内层列 = 外层表达式中的列），则不进行消除。

四、金仓数据库的实现路径

金仓数据库在V009R002C014版本中实现的标量子查询消除机制，遵循了一条清晰的三阶段路径。

4.1 阶段一：等价性判定

在查询的语法分析（parse）和逻辑优化（rewrite）阶段，优化器会遍历查询树中的每一个标量子查询节点。判定过程如下：

检查子查询是否出现在SELECT列表中。目前版本只针对SELECT列表中的标量子查询进行消除，WHERE/HAVING中的暂不处理。
检查子查询的结构。子查询必须是一个"简单"的查询块：可以包含聚合函数、GROUP BY、WHERE条件、JOIN，但不能包含窗口函数、UNION、DISTINCT、LIMIT/OFFSET等复杂子句。
验证标量语义。根据前面提到的规则，确认子查询最多返回一行。对于包含GROUP BY的情况，检查分组键是否是基表的唯一键（依赖元数据中的主键/唯一约束信息）。

4.记录聚合函数信息。遍历子查询的目标列表，识别每个聚合函数的类型（COUNT/SUM/AVG/MAX/MIN），为后续生成COALESCE做准备。

提取相关条件 。识别子查询WHERE条件中引用外层查询列的谓词。目前只支持形如inner.column = outer.column或inner.column = outer.column + constant的简单等值条件。

只有通过上述所有检查的子查询，才会被标记为"可消除"。

4.2 阶段二：转换为外连接

对于被标记为可消除的标量子查询，优化器执行以下转换步骤：

提取内层查询的基表和JOIN关系。将子查询的FROM部分独立出来，作为内联视图的FROM子句。
提取GROUP BY键。如果子查询原本有GROUP BY，则保留；如果没有GROUP BY但包含聚合函数，则创建一个空的GROUP BY（即全局聚合）。如果子查询既没有GROUP BY也没有聚合函数，但通过了标量语义验证（比如WHERE条件限定了唯一键），则GROUP BY键设置为该唯一键。
构建聚合表达式列表。将子查询SELECT列表中的每个聚合表达式（或非聚合表达式，如果是唯一键情况）作为内联视图的输出列。
生成左外连接 。以原始的外层查询作为左表，内联视图作为右表，连接条件为提取出来的相关条件的反转（原来的inner.col = outer.col变成outer.col = inner.col）。
处理外层SELECT列表。将原来对标量子查询的引用，替换为对内联视图输出列的引用，并根据聚合函数类型决定是否包裹COALESCE。
清理和简化。如果原始子查询中还包含其他与消除无关的表达式（比如子查询的WHERE条件中除了相关条件外还有本地过滤条件），这些本地条件会被保留在内联视图中。

这个转换步骤在优化器的内部表示中是一个重写规则（rewrite rule）。在KingbaseES的优化器代码中，这个规则被命名为flatten_scalar_subquery（当然，这是基于我对开源PostgreSQL优化器的了解所做的推测，金仓的实现有自己独立的一套框架）。

4.3 阶段三：相似子查询合并

这是金仓方案中的一个亮点。在完成基本的消除转换之后，优化器会再执行一轮"合并"优化：扫描外层查询的SELECT列表，找到所有被替换为内联视图引用的标量子查询消除结果，按照以下规则进行合并：

同一张基表：内联视图查询的FROM子句中引用的基表集合必须完全相同（包括JOIN关系）。
相同的连接条件：与外层查询进行连接的条件在结构上一致。
相同的GROUP BY键：内联视图的分组键必须一致。
相同的本地过滤条件：内联视图WHERE子句中的非连接条件必须完全相同。

如果多个标量子查询满足上述条件，优化器将它们合并为一个内联视图。合并后的内联视图的SELECT列表会包含所有被消除子查询的聚合表达式（以及非聚合表达式，如果有的话）。外层查询中对应的列引用会被重新指向这个合并后的内联视图的不同输出列。

合并能够显著减少对同一个基表的扫描次数。在极端情况下，如果一个外层查询的SELECT后面挂了20个标量子查询，且它们都指向同一张事实表，合并后事实表只被扫描一次，而不是20次。

4.4 一个完整的示例

让我们用金仓数据库实际执行一下前面那个包含三个标量子查询的SQL，看看优化器生成的执行计划。

sql 复制代码

EXPLAIN (VERBOSE, COSTS OFF)
SELECT o.order_id,
       (SELECT SUM(oi.quantity * oi.price) FROM order_items oi WHERE oi.order_id = o.order_id) AS total_amount,
       (SELECT COUNT(*) FROM order_items oi WHERE oi.order_id = o.order_id) AS item_count,
       (SELECT AVG(oi.price) FROM order_items oi WHERE oi.order_id = o.order_id) AS avg_price
FROM orders o;

在未开启标量子查询消除的情况下（或者在一个不支持该功能的数据库中），执行计划可能会显示为：

sql 复制代码

Seq Scan on orders o
  SubPlan 1 (correlated)
    ->  Aggregate
          ->  Index Scan using idx_order_items_order_id on order_items oi
  SubPlan 2 (correlated)
    ->  Aggregate
          ->  Index Scan using idx_order_items_order_id on order_items oi
  SubPlan 3 (correlated)
    ->  Aggregate
          ->  Index Scan using idx_order_items_order_id on order_items oi

三个独立的SubPlan，每个都是correlated（相关子查询）。

在金仓数据库中开启优化后，执行计划变成：

sql 复制代码

Hash Left Join
  Hash Cond: (o.order_id = agg.order_id)
  ->  Seq Scan on orders o
  ->  Hash
        ->  Subquery Scan on agg
              ->  HashAggregate
                    Group Key: oi.order_id
                    ->  Seq Scan on order_items oi

这里可以看到，order_items只被扫描了一次（Seq Scan），然后通过哈希聚合（HashAggregate）计算出所有需要的聚合值，最后和orders表做哈希左外连接。三个标量子查询完全消失了。

五、实践验证：从数据中看效果

理论说得再多，不如一次实测算得准确。我按照金仓官方文档中的测试方法，在一个标准环境中完成了性能对比。

5.1 测试环境

金仓数据库 V009R002C014
操作系统：CentOS 7.9
CPU：Intel Xeon Gold 5118 @ 2.30GHz (4核)
内存：8GB
存储：SSD

5.2 测试数据准备

sql 复制代码

-- 建表
CREATE TABLE t1 (id numeric(10,1));
CREATE TABLE t2 (id numeric(10,1));

-- 插入10000条数据
INSERT INTO t1 VALUES (generate_series(1, 10000));
INSERT INTO t2 VALUES (generate_series(1, 10000));

-- 创建索引（模拟真实场景）
CREATE INDEX idx_t2_id ON t2(id);

-- 更新统计信息
ANALYZE t1;
ANALYZE t2;

5.3 测试查询

sql 复制代码

-- 查询1：原始标量子查询
SELECT (SELECT SUM(id) FROM t2 WHERE t1.id = t2.id) FROM t1;

5.4 测试结果

场景	执行时间	对t2表的扫描次数
标量子查询未消除（模拟）	32.4秒	10000次
金仓自动消除后	24毫秒	1次

执行时间从32.4秒降到24毫秒，性能提升了约1350倍。这不仅仅是量变，而是质变------从用户无法接受的等待时间，变成了几乎瞬时的响应。

5.5 不同数据量下的性能对比

为了观察扩展性，我分别测试了不同数据量下的表现：

t1行数	未消除（秒）	消除后（秒）
1000	3.2	0.003
5000	16.1	0.012
10000	32.4	0.024
20000	65.2	0.048

未消除版本的时间与t1行数呈线性增长，而消除后的版本也呈线性增长，但斜率完全不同。前者每增加10000行需要额外32秒，后者只需要额外24毫秒。这个差距在更大的数据集上会更加惊人。

六、对标量子查询消除的再思考

6.1 为什么不是所有数据库都实现了？

既然标量子查询消除的效果如此明显，为什么不是所有数据库都实现了它？我在和几个数据库内核开发者的交流中了解到，主要有以下几个原因：

语义安全性难以权衡。如前所述，COUNT的特殊性、多行返回的风险、相关条件的复杂性，都让实现变得棘手。一个不小心，优化就会改变结果，这是任何商业数据库都不能接受的。
优化器架构的限制。很多数据库的优化器是基于启发式规则的，规则触发的顺序、条件判断的复杂性，都会影响消除的效果。要安全地实现标量子查询消除，往往需要引入更复杂的代价模型和语义推理能力。
真实负载中并不总是受益。对于小数据量、高频OLTP查询，标量子查询消除带来的收益不明显，反而可能增加优化时间。一些数据库因此选择保守策略。
历史包袱。一些老牌数据库的核心优化器代码已经积累了数十年，修改任何一部分都可能引发连锁反应。重构优化器的风险太高，而增加新功能往往只针对当前版本的新语法。

6.2 金仓方案的技术取舍

从设计文档和实测表现来看，金仓的标量子查询消除方案做了几个明智的取舍：

优先保证正确性：只对绝对安全的子查询进行消除。宁可漏掉一些优化机会，也不冒险改变语义。这是一种工程上的务实选择。

聚焦SELECT列表：先解决80%的问题。SELECT列表中的标量子查询是性能问题的重灾区，优先处理这一部分就能带来巨大的收益。WHERE条件中的标量子查询消除更复杂，留待后续版本。

相似合并作为增值特性：合并相似子查询不是每个数据库都有的功能。金仓将其纳入，说明对报表类查询场景有深入理解。

与整体优化器框架的集成：据我了解，金仓的优化器具备完善的代价模型和改写框架。标量子查询消除被实现为一个独立的改写规则，可以与其他的优化规则（如谓词下推、连接重排序）协同工作。

6.3 2026年的视角：HTAP时代的新意义

2026年，数据库领域的一个显著趋势是HTAP（混合事务/分析处理）架构的普及。越来越多的企业希望用一套数据库系统同时支撑高并发的事务处理和海量的分析查询。在这种背景下，标量子查询消除获得了一个新的价值维度。

在传统的事务处理系统中，开发人员被鼓励避免复杂的子查询，因为事务处理的延迟敏感。但在分析查询中，复杂的子查询又是不可避免的------业务分析人员需要灵活地计算各种派生指标。如果数据库不能高效执行这些查询，企业就不得不维护两套系统（OLTP+OLAP），承受数据同步的延迟和额外的运维成本。

标量子查询消除技术的成熟，意味着数据库可以在不要求用户改变SQL写法的情况下，自动将分析型的子查询转换为高效的执行计划。这降低了HTAP落地的门槛------应用开发团队可以继续使用他们习惯的、可读性高的SQL写法，而数据库后端会自动进行性能优化。

从这个角度看，金仓在标量子查询消除上的投入，不仅仅是解决了一个具体的性能问题，更是在夯实其HTAP能力的基础。

七、总结与展望

标量子查询消除，从表面上看是一个简单的SQL改写技巧，但深入到数据库内核层面，它涉及语义等价性验证、聚合函数空值处理、相关子查询解关联、相似模式识别等一系列复杂问题。金仓数据库在V009R002C014版本中给出的答案：通过三阶段的流程（等价判定、消除转换、相似合并），在保证语义正确的前提下，实现了对SELECT列表中标量子查询的自动优化。

实测数据表明，在10000行的数据规模下，消除后的查询性能提升了三个数量级以上。对于报表类、统计类的复杂查询，这种优化带来的改善是立竿见影的。

当然，这项工作远未到终点。未来可以探索的方向还有很多：支持WHERE子句中的标量子查询消除，处理包含窗口函数或UNION的复杂子查询，支持更智能的相似子查询合并（包括谓词差异的合并），以及结合代价模型动态决定是否消除（当外表数据量很小时，嵌套循环可能比哈希连接更优）。

对于DBA和开发人员来说，了解标量子查询消除的存在，并不意味着可以随意写出性能低下的SQL。但知道数据库在背后默默帮你做了优化，至少可以让你在写SQL时少一些焦虑，把更多的精力放在业务逻辑本身------这也许正是数据库技术应有的样子。