活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# GBase 8a 嵌套子查询改写时的边界和风险

我最近看资料和整理复杂 SQL 排查记录时，越来越觉得 GBase 8a 里很多“这条 SQL 能不能再简化一下”的讨论，最后真正的风险不在简不简，而在**嵌套子查询改写之后，业务语义有没有被悄悄带偏**。

现场里很常见：
有人觉得 SQL 套太多层，就直接把子查询展开；有人把 `in` 改成 `join`，把 `exists` 改成普通关联，结果执行虽然通了，但返回记录数和原来不一样；还有一些场景里，原本子查询承担的是筛选语义，改写后却引入了重复行，最后聚合结果全变了。

我自己理解下来，这类问题和单纯的性能调优不是一回事。
它更接近**SQL 改写边界和结果语义保护**。
真正到现场时，改写当然可以做，但我自己更关注的是：改写后的语句到底是不是还在回答同一个业务问题。

## 为什么子查询改写这么容易出问题

我最近整理下来觉得，核心原因通常有两个：

1. 原 SQL 的语义没有先被说清楚；
2. 改写时只盯结构简化，没盯结果集合变化。

比如 `in`、`exists`、`join` 看起来都能把两张表联系起来，但它们在“是否引入重复行”这件事上并不等价。
如果不先明确原 SQL 想拿的是“存在性判断”还是“明细连接结果”，后面很容易越改越偏。

## 一个更接近现场的例子

原始 SQL：

```sql
select *
from fact_order o
where o.user_id in (
    select user_id
    from dim_user_tag
    where tag_code = 'NEW_USER'
);
```

这条 SQL 的业务语义很明确：
只筛出“属于新客标签集合”的订单。

但现场里很容易有人把它改写成：

```sql
select o.*
from fact_order o
join dim_user_tag t
  on o.user_id = t.user_id
where t.tag_code = 'NEW_USER';
```

这条改写表面看起来没问题，但如果 `dim_user_tag` 里同一个 `user_id` 有多条 `NEW_USER` 记录，结果就会引入重复订单。
这时候如果下游还做聚合，结果偏差会被继续放大。

我自己更关注的一点就是：
**原 SQL 要的是集合筛选，改写后却变成了明细连接。**

## 我实际排查时一般先看什么

### 第一步：先定义原 SQL 的业务语义

是要筛存在、取唯一集合，还是要拿明细关联结果？
如果这一步没说清楚，后面改写几乎一定会出争议。

### 第二步：检查子查询是否天然去重

像 `in`、`exists` 这类写法，很多时候业务只关心“有没有”，并不关心右表明细有几行。
改写成 join 以后，这个语义常常就变了。

### 第三步：对照改写前后结果集粒度

我自己更倾向于至少做三组对照：

- 总行数；
- 主键去重后行数；
- 聚合后的关键指标。

只看其中一项，很容易误判。

## 哪几类改写我最谨慎

| 改写方向 | 我为什么谨慎 |
|---|---|
| IN 改 JOIN | 可能引入重复行 |
| EXISTS 改 JOIN | 存在性语义变成明细语义 |
| 多层子查询直接展开 | 过滤边界更难看清 |
| 先筛后聚合改成先聚合后筛 | 指标口径可能变掉 |

## 一个我更倾向的改写方式

如果确实要把集合筛选改写得更清晰，我自己更愿意先把右侧集合去重后再连接。

```sql
select o.*
from fact_order o
join (
    select distinct user_id
    from dim_user_tag
    where tag_code = 'NEW_USER'
) t
  on o.user_id = t.user_id;
```

这样至少把“存在性集合”保住了，不容易直接放大重复。

## 我实际排查时经常做的对照 SQL

```sql
-- 原写法
select count(*) as cnt_in
from fact_order o
where o.user_id in (
    select user_id
    from dim_user_tag
    where tag_code = 'NEW_USER'
);

-- 直接 join 写法
select count(*) as cnt_join
from fact_order o
join dim_user_tag t
  on o.user_id = t.user_id
where t.tag_code = 'NEW_USER';

-- 去重后 join 写法
select count(*) as cnt_distinct_join
from fact_order o
join (
    select distinct user_id
    from dim_user_tag
    where tag_code = 'NEW_USER'
) t
  on o.user_id = t.user_id;
```

这组三对照在现场特别有用。
因为它能快速告诉你，改写后到底是结构变了，还是结果也变了。

## 一些我实际见过的坑

### 坑一：觉得 join 写法更“标准”，就默认替换

### 坑二：子查询展开后，筛选条件散在多个位置

### 坑三：改写时忘了原 SQL 是按集合语义工作的

### 坑四：只比执行是否成功，不比结果是否一致

| 常见坑 | 现场表现 | 我更建议的处理 |
|---|---|---|
| 直接把 IN 改 JOIN | 结果放大 | 先看右表是否唯一 |
| EXISTS 改 JOIN | 明细数突增 | 保住存在性语义 |
| 只测样例数据 | 误以为没问题 | 加总量和去重对照 |
| 不留原 SQL 对照 | 回退困难 | 保留原写法核对 |

## 一个简单的核对脚本

```bash
#!/bin/bash

DBHOST=192.0.2.148
DBPORT=5258
DBNAME=dw_sql
DBUSER=sql_user
LOGDIR=/data/gbase/log/subquery_check
DAYSTR=$(date +%F)

mkdir -p "${LOGDIR}"

gccli -h ${DBHOST} -P ${DBPORT} -u ${DBUSER} ${DBNAME} &lt;&lt;'SQL' &gt;&gt; "${LOGDIR}/subquery_check_${DAYSTR}.log" 2&gt;&amp;1
select count(*) as cnt_in
from fact_order o
where o.user_id in (
    select user_id
    from dim_user_tag
    where tag_code = 'NEW_USER'
);

select count(*) as cnt_join
from fact_order o
join dim_user_tag t
  on o.user_id = t.user_id
where t.tag_code = 'NEW_USER';
SQL
```

## 结尾

我最近回头看 GBase 8a 里这类 SQL 改写问题时，一个很明显的感受是：
子查询改写最容易出问题的地方，不是语法本身，而是我们太容易把“写法更直”误当成“语义没变”。

真正落到现场时，先定义原 SQL 想回答什么，再决定能不能改、怎么改，通常会比直接动手改写更稳。

## 参考资料

```text
[1] GBase 社区个人中心
https://www.gbase.cn/community/user/46723

[2] GBase 8a 社区优质文章区
https://www.gbase.cn/community/section/11

[3] GBase 8a MPP Cluster SQL 参考手册
https://www.gbase.cn/community/post/1772

[4] GBase 8a
https://www.gbase.cn/community/section/11
```





GBase 8a 嵌套子查询改写时的边界和风险

GBase 8a 嵌套子查询改写时的边界和风险

评论

热门帖子