被一个标量子查询折腾了两天后来发现是数据库自己“偷了懒”

先交代一下背景。去年帮一个做电商的客户排查性能问题。对方说有一个统计报表越来越慢，从原来的秒级响应变成了半分钟。我说你把你那个慢SQL发给我看看。

对方发过来的SQL长这样：

SELECT FROM orders WHERE customer_id = c.id) AS total。FROM orders WHERE customer_id = c.id) AS cnt,c.name
FROM customers c;老实说，

我一看。customers 表大概 10 万行，orders 表也是 10 万行。这个SQL的意思很直接：每个客户的消费总额和订单数。

但执行的时候出事了。orders 表被扫了两万次。你没看错，两万次，因为对每一个客户，数据库都要跑到 orders 表里算一次 SUM。再算一次 COUNT，接下来才处理下一个客户。

10 万 × 10 万 = 10 亿次全表扫描。

我当时的第一反应不是“这个SQL写得太烂”，因为业务逻辑上它就是需要这么查。我的第一反应是：“这调整器怎么这么死脑筋？明明可以提前把聚合结果算好，接下来只做一次连接就行了。”

后来我把他们的数据迁移到新版本的金仓数据库上。一样的SQL，一句没改，执行时间从 30 秒掉到了 20 毫秒。

客户在群里发了三个问号：“你改啥了？怎么说呢，”

从我说来看。“我啥也没改，就是数据库自己变聪明了。”

说到痛点一，标量子查询导致多次全表扫描

先解释一下什么叫标量子查询。按理说，就是 SELECT 后面跟一个括号包起来的查询。这个查询只能返回一个数，上面例子里的两个子查询都是这种。

传统数据库执行这种SQL的方式，说白了就是“傻跑”：先执行外层查询。拿到一个客户 id，接下来带着这个 id 去 orders 表里做一次聚合，返回结果，再继续下一个客户。

再看者痛点，手动 SQL 的痛苦与风险

• 时间成本高：需要手工拆分子查询、重写 JOIN、调试验证结果是否一致。
• 错误隐患：任何微小差异都会导致业务数据错误，而错误往往不易被立即发现。老实说，
• 维护成本升高：后续再修改业务逻辑时还得重新评估 SQL 是否还能保持等价性。

痛点二这方面，调整器不敢随便改，导致性能瓶颈持续存在

• COUNT 与 NULL 的语义差异：If 一个客户根本没有订单。子查询里的 COUNT 会返回 0，但如果改成 LEFT JOIN，没有匹配的行会得到 NULL，这在业务逻辑里可能产生误判。
• 多行返回风险：标量子查询只能返回一行，否则会报错；改为 JOIN 多行会被合并成一行且不报错，却导致数据错误更难检测。话说回来，
• 等价性判断复杂：# 必须保证所有条件满足：聚合函数、等值关联、无 GROUP BY/HING/LIMIT 等等。否则调整器不会动手，

从方法来看，金仓调整器自动消除标量子查询

# 步骤一：确认数据库版本支持该调整功能

# 步骤二：检查子查询结构是否满足等价性规则

• No GROUP BY / HING / LIMIT / DISTINCT / 窗口函数等复杂表达式
• "WHERE" 条件使用等值比较且无非等值关联
• "COUNT" 在无匹配时需显式处理为 0 而非 NULL

# 步骤三：升级或开启相应配置即可。让调整器自动完成以下工作：

• 将多个标量子查询转换为一次 LEFT JOIN 或 HASH JOIN，并在 join 子句中使用预聚合结果集。→ orders 表仅扫一次而不是十万次。→ 执行时间从几百毫秒降至几毫秒，实现千倍以上加速。

实例演示这方面，从“十万循环”到“一次扫描”

CREATE TABLE t1;CREATE TABLE t2;INSERT INTO t1 SELECT generate_series;INSERT INTO t2 SELECT generate_series;-- 原始
EXPLAIN ANALYZE
SELECT FROM t2 WHERE t1.id=t2.id) FROM t1;-- 调整后
EXPLAIN ANALYZE
SELECT sum FROM t1
LEFT JOIN t2 ON t1.id=t2.id GROUP BY t1.id;

•  节点已消失；loops 从 10000 降至 0.
• 执行时间从约 500ms 降至约 0.8ms.

再看进一步提高，多重聚合函数同表同条件时一次扫描搞定所有指标

SELECT
FROM orders WHERE customer_id = c.id AND status='completed')。FROM orders WHERE customer_id = c.id AND status='completed'),FROM orders WHERE customer_id = c.id AND status='completed'),c.name
FROM customers c;

ID 一样可三种指标，只需一次对 orders 的全表扫描；若手工 则仍需三次扫描——极度低效且易出错！

让调整器成为真正的“工程师”而非单纯会计师

• No More Manual Rewrite: 代码保持原始可读性，无需拆解为大量 JOIN 与临时表；只要升级数据库即可享受性能提高。
• No More Hidden Bugs: 自动化消除多余扫描与语义偏差，确保业务正确性与高效运行并存。

If you see a  node with a huge loops number in your execution plan,it's almost certainly an unoptimized scalar subquery.

• Create an index on foreign key column if not already present.