活动专区

活动公告

上车！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 常用函数、表达式

事实表按天、按月暴涨时，很多团队会在 8a 上建**分区表**，指望查询只扫「相关分区」、加载只写「当天分区」。现场却常见两种反差：DDL 明明写了 `PARTITION BY RANGE`，业务 SQL 也带了日期条件，**EXPLAIN 仍扫全部分区**；或者裁剪看似生效，但 **Motion 之后又在全量数据上做聚合**，体感依旧很慢。

8a 是 MPP：分区裁剪发生在**各数据节点本地扫描之前**；若 WHERE 写法、函数包裹、类型隐式转换让优化器无法把谓词下推到分区边界，就会退化成**全分区扫描 + 跨节点洗牌**。本文讲分区键怎么选、怎样用 EXPLAIN 判断裁剪是否生效，并给一套可执行的排查顺序。

## 一、分区在 8a 计划里解决什么问题

分区不是索引的替代品，主要价值是：

| 能力 | 对计划/运维的意义 |
|------|-------------------|
| **分区裁剪（Pruning）** | 查询只打开满足条件的分区，减少本地扫描量 |
| **加载与删除边界** | `LOAD`/`INSERT` 定向分区；按分区 `TRUNCATE` 归档历史 |
| **并行度与倾斜** | 分区过粗 → 单分区仍巨大；过细 → 元数据与打开分区成本高 |

在 EXPLAIN 或执行详情里，应能看到**参与扫描的分区列表明显少于总分区数**。若业务只查近 7 天，却出现几十个 `Partition Scan`，说明裁剪未生效或条件不可推导。

## 二、分区键选型：RANGE、LIST 与分布键的关系

**RANGE（按日期/数值区间）** 最适合流水、日志、订单按 `dt` 或 `id` 递增的场景。键列应满足：

1. **与查询谓词同一列、同一类型**（`DATE` 对 `DATE`，避免 `dt` 是 `CHAR` 而条件写 `DATE '2026-05-01'` 隐式转换）。
2. **尽量出现在 WHERE 的「裸列」上**，不要 `WHERE DATE_FORMAT(dt,'%Y%m')='202605'` 这种对分区列套函数。
3. **与表分布键可以不同**：分布键决定行落在哪个节点；分区键决定节点上打开哪些文件/子表。Join 频繁的两张表，仍要单独评估**分布键是否对齐**，不能指望分区 alone 消除 REDISTRIBUTE。

**LIST（按枚举）** 适合省份、渠道、产品线等离散值；注意枚举值新增时要 `ADD PARTITION`，否则数据进默认分区后查询容易「以为裁剪了、实际扫默认分区」。

示例（语法以版本文档为准）：

```sql
CREATE TABLE fact_orders (
  order_id   BIGINT,
  cust_id    INT,
  dt         DATE,
  amt        DECIMAL(18,2)
)
DISTRIBUTED BY ('cust_id')
PARTITION BY RANGE (dt) (
  PARTITION p202601 VALUES LESS THAN ('2026-02-01'),
  PARTITION p202602 VALUES LESS THAN ('2026-03-01'),
  PARTITION p202603 VALUES LESS THAN ('2026-04-01')
);
```

这里 `cust_id` 负责 MPP 分片，`dt` 负责分区内裁剪——改 SQL 时两条线都要看。

## 三、让裁剪生效的 SQL 写法

下列写法在多数 MPP 库（含 8a）上容易导致**裁剪失败**，排查时优先对照：

| 写法 | 问题 | 建议改法 |
|------|------|----------|
| `WHERE YEAR(dt)=2026` | 对分区列套函数 | `dt &gt;= DATE '2026-01-01' AND dt &lt; DATE '2027-01-01'` |
| `WHERE dt = '20260520'`（列是 DATE） | 隐式转换 | 统一类型，用 `DATE '2026-05-20'` |
| 分区列在 OR 一侧 | 优化器难推导 | 改 `UNION ALL` 各写确定区间 |
| 子查询里过滤、外层再 Join | 谓词未下推 | 尽量把 `dt` 条件下推到最内层扫描 |

推荐业务查询模板：

```sql
EXPLAIN
SELECT region, SUM(amt)
FROM fact_orders
WHERE dt &gt;= DATE '2026-05-01'
  AND dt &lt;  DATE '2026-05-08'
GROUP BY region;
```

阅读 EXPLAIN 时记录：**扫描的分区名/个数**、是否在扫描后出现不必要的 **REDISTRIBUTE**。裁剪成功但 Join 键与分布键不一致，仍会大洗牌——这是「分区对了、整体仍慢」的常见原因。

## 四、案例：谓词写错导致「假分区表」

**场景**：`fact_orders` 按 `dt` RANGE 日分区，共 90 个分区；报表 SQL 使用 `WHERE dt BETWEEN '20260501' AND '20260507'`（字符串），列类型为 `DATE`。白天查询耗时从预期的十几秒升到 3 分钟。

**EXPLAIN 现象**：

- 计划中出现**全部分区**或接近全量的 `Partition Scan`
- 估算行数接近整表，随后 **REDISTRIBUTE** 按 `region` 重分布

**根因**：字符串与 `DATE` 比较触发隐式转换，优化器无法把边界映射到分区元数据，裁剪失效；大扫描放大后续 Motion 成本。

**处理**：

1. 改写为 `dt &gt;= DATE '2026-05-01' AND dt &lt; DATE '2026-05-08'`
2. 对表做 `ANALYZE`（统计信息过旧会放大错误计划，见专文）
3. 再次 `EXPLAIN`，确认分区扫描收窄、行数估计下降

**结果**：本地扫描量下降一个数量级，查询回到数十秒级；若仍慢，再查 Join 分布键与锁。

## 五、加载、归档与变更窗口

| 场景 | 建议 |
|------|------|
| 日增量加载 | 明确目标分区；避免误写默认分区 |
| 历史归档 | 按分区 `TRUNCATE`/交换，而非 `DELETE` 全表扫 |
| 新增月份 | 提前 `ADD PARTITION`，避免高峰写默认分区 |
| 变更后验证 | 对核心 SQL 跑一轮 `EXPLAIN` 对比裁剪前后 |

```sql
-- 维护示例（以现场语法为准）
ALTER TABLE fact_orders ADD PARTITION p202604
  VALUES LESS THAN ('2026-05-01');
```

## 六、排查清单（与慢 SQL、统计信息衔接）

```text
[1] 确认表为分区表，记录分区列、分区粒度、总分区数
[2] 检查 WHERE 是否对分区列使用函数、隐式类型转换
[3] EXPLAIN：参与扫描的分区是否远小于总分区
[4] 裁剪正常仍慢 → 查分布键、Join 键、Motion（REDISTRIBUTE/BROADCAST）
[5] 行数估计离谱 → ANALYZE 后再比计划
[6] 加载脚本是否写入错误分区（默认分区堆积）
```

## 小结

GBase 8a 的分区表要同时管好 **MPP 分布键** 与 **分区裁剪键**：前者决定数据在集群怎么摊，后者决定每个节点扫多少。把日期条件写成**可推导的区间谓词**，用 `EXPLAIN` 验证分区扫描范围，再与分布键、统计信息一起排查，能避免「建了分区却当全表扫」的运维落差。建议把典型坏 SQL 与改后计划截图纳入案例库，方便 BI 与开发对照修改。




性能调优

GBase 8a 分区表实战：分区键选型与裁剪失效排查

GBase 8a 分区表实战：分区键选型与裁剪失效排查

评论

热门帖子