活动专区

活动公告

上车！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 空洞率治理和历史数据清理

我最近看 GBase 8a 这块资料时，越来越觉得很多环境里真正难处理的，不是“数据删不掉”，而是“数据看起来删了，空间却没回来，查询还越来越慢”。现场里最常见的情况就是：业务按天、按月删历史数据，表面上逻辑已经清掉了，但磁盘占用没明显下降，扫描效率也没跟着恢复。后面一看，问题往往都落在同一个点上——**GBase 8a 的删除并不等于物理空间立即释放**，长期累积以后，空洞率、空间占用和查询代价会一起冒出来。

我自己理解下来，GBase 8a 这类场景里，“历史数据治理”最好别只理解成一条 `delete`。真正落到现场时，更实际的处理顺序通常是下面这几件事：

1. 先判断这张表到底适不适合直接 `delete`。
2. 再判断应该用分区清理、`shrink space`，还是重建表。
3. 最后把检查、执行窗口、校验和回退一起补齐。

很多项目后面治理越来越重，不是不会清理，而是一开始把“删除数据”和“回收空间”当成了一回事。

## 我一般先把这类问题分成几种场景

| 现场现象 | 我优先怀疑的点 | 第一动作 |
|---|---|---|
| 删了很多历史数据，磁盘还是没降 | 逻辑删除后空间没回收 | 先看空洞率和表占用 |
| 表越跑越慢，但数据量没有继续涨很多 | 空洞率升高，扫描代价变大 | 看是否存在大量已删标记数据 |
| 时间型大表定期清理很麻烦 | 表设计没有给生命周期留出口 | 先考虑分区或天表 |
| 小表频繁更新删除，长期变碎 | 更适合定期压缩或重建 | 评估 `shrink space full` 窗口 |
| 想马上回空间，但业务不能长时间停 | 清理方式选错了 | 比较分区删除、`shrink` 和重建代价 |

我最近整理下来觉得，GBase 8a 的生命周期治理，最怕的不是“没有手段”，而是**不同表用同一种办法硬套**。大表、小表，时间边界明确和边界不明确，代价差别非常大。

## 一、先把“删除数据”和“回收空间”分开理解

这个点我现在会先跟团队说清楚。
GBase 8a 删除数据以后，并不会立刻把磁盘空间物理释放掉，而是先把对应数据标记成已删除状态。这样做的好处是删除动作本身更直接，但后面就会带来两个常见问题：

- 磁盘空间没有按预期回来。
- 已删除数据比例高了以后，表扫描和查询会更浪费资源。

这也是为什么很多环境里，业务已经持续做历史清理了，但表还是越来越“胖”。

### 这个现象我通常怎么判断

我现场里一般不会先做清理，而是先拉一轮表级信息，确认这张表是不是已经值得动了：

```sql
select *
from performance_schema.tables
where TABLE_SCHEMA = 'ods'
  and TABLE_NAME = 'order_hist';
```

如果是已经知道表特别大、而且近期确实删过很多数据，我还会把“业务上删掉了多少”和“物理空间有没有明显回落”放在一起看。这个动作很简单，但很关键，因为有些表看起来删了很多，实际可释放空间并不大；有些表则反过来，删掉的数据占比已经不低，但还没人处理。

## 二、别一上来就 `shrink space`，先看这张表属于哪一类

GBase 8a 这块我后来越来越认同一个思路：
**先分表类型，再选回收方式。**

### 我自己更常用的分类办法

| 表类型 | 我更倾向的处理方式 | 原因 |
|---|---|---|
| 明显按时间增长的大表 | 优先考虑天表或分区表 | 生命周期边界明确，清理成本最低 |
| 已经建好的普通大表 | 评估 `shrink space` / `shrink space full` / 重建表 | 看窗口、可释放空间和阻塞代价 |
| 小表但频繁更新删除 | 定期 `shrink space full` 或重建 | 表小，治理窗口更容易拿 |
| 需要快速整月、整天清理的数据 | 分区删除或分区截断 | 比逐行 `delete` 更直接 |
| 长期没有分区、数据量特别大 | 不急着直接压缩，先算代价 | 很多时候先补生命周期设计更值 |

我个人比较在意一个点：
**如果数据本身有天然时间边界，最优解通常不是 delete 之后再补救，而是从表结构层面就给清理动作留出口。**

## 三、时间边界清楚的大表，我更倾向优先做分区治理

社区里关于 GBase 8a 分区表的资料，我自己觉得有个点特别实用：
分区不只是为了查询裁剪，也非常适合做生命周期管理。因为对有明显时间边界的数据来说，“整段清理”本来就比“逐行删除”更自然。

### 一个比较常见的 RANGE 分区示意

```sql
create table ods.order_hist (
  order_id        bigint,
  cust_id         bigint,
  statis_date     date,
  order_amt       decimal(18,2)
)
partition by range (year(statis_date) * 100 + month(statis_date)) (
  partition p202401 values less than (202402),
  partition p202402 values less than (202403),
  partition p202403 values less than (202404),
  partition pmax values less than maxvalue
);
```

这种设计的好处很实际：

- 数据按月份分段，生命周期边界清楚。
- 查询按时间条件时，更容易缩小扫描范围。
- 清理时可以按分区动作做，不用靠大批量 `delete`。

### 分区治理里我更常用的几个动作

```sql
-- 增加新分区
alter table ods.order_hist
add partition (partition p202404 values less than (202405));

-- 删除旧分区
alter table ods.order_hist
drop partition p202401;

-- 截断指定分区
alter table ods.order_hist
truncate partition p202402;
```

这里我自己会提醒团队两个很实在的点：

1. **`drop partition` 是直接删除该分区数据的，先备份再做。**
2. **分区适合有明确边界的数据，不适合所有表都机械上。**

如果业务本来就是按月、按天沉淀历史数据，那分区几乎天然适合做生命周期管理。
但如果表里的清理边界很散，硬上分区也不一定真的省事。

## 四、普通表已经出现空洞率问题时，我一般先评估 `shrink space` 还是 `shrink space full`

这块也是 GBase 8a 现场里最容易被直接上命令的地方。
我自己现在不会一看到空间没回来就立刻跑 `alter table ... shrink space`，因为不同模式的代价和效果差别挺大。

社区里关于 `shrink space` 的资料已经把几个模式差异讲得比较清楚了。按我目前整理下来的理解，大致可以这样看：

| 方式 | 我更倾向怎么理解 | 适用场景 |
|---|---|---|
| `shrink space` | 回收较快，但空间释放不一定彻底 | 业务窗口短、先想止血 |
| `shrink space full` | 更彻底，更像深度整理 | 表不算太大，能拿到窗口 |
| `shrink space full block_reuse_ratio=N` | 在释放率和耗时之间做折中 | 想比普通 shrink 更彻底，但又不想全量极限整理 |
| 重建表 | 最可控，也最像重新整理一次 | 能接受重建成本，且想把格式和结构一起理顺 |

### 一个常见的回收示意

```sql
alter table ods.order_hist shrink space;

alter table ods.order_hist shrink space full;

alter table ods.order_hist shrink space full block_reuse_ratio=30;
```

### 我自己更常这样选

| 场景 | 我更倾向的方式 |
|---|---|
| 大表、短窗口、先回一部分空间 | `shrink space` |
| 小表、频繁更新删除、想定期整理 | `shrink space full` |
| 大表但可释放空间不少，且想折中 | `shrink space full block_reuse_ratio` |
| 业务能接受重建 | 重建表 |

这个地方我个人最想强调的是：
**`shrink space` 不是“想什么时候跑就什么时候跑”的轻操作。**
社区资料里提到，这类动作本质上是 DDL，执行期间会对表访问产生影响。采用 rebalance 方式时，可以放松部分限制，但也不是完全无影响。所以真正落到生产，窗口期一定要先拿到。

## 五、重建表这件事，很多时候比硬压缩更稳

有些现场里，一提空间回收，大家第一反应就是 `shrink`。但我自己做下来，反而觉得重建表有时候更容易把风险讲清楚。尤其是下面几类情况：

- 表已经很碎，业务也能接受一次集中窗口。
- 想顺手把存储属性、分布方式或者字段顺序也一起整理。
- 当前版本和现场条件下，不想把空间整理全部压在单个 `shrink` 动作上。

### 我更常用的一种重建思路

```sql
create table ods.order_hist_new like ods.order_hist;

insert into ods.order_hist_new
select *
from ods.order_hist
where statis_date &gt;= '2024-01-01';

rename table ods.order_hist to ods.order_hist_bak;
rename table ods.order_hist_new to ods.order_hist;
```

再配合业务窗口和抽样校验，把原表保留一段时间后再删：

```sql
drop table ods.order_hist_bak;
```

这种方式的好处不是“更高级”，而是更容易把步骤拆清楚：

1. 先生成新表。
2. 再导数据。
3. 再校验。
4. 最后切换。

对于那些已经很臃肿、而且后续还想顺手整理结构的表，我自己更倾向把重建当成一条正式治理路线，不会只把它当成最后兜底。

## 六、真正落地时，我更喜欢先做一轮“候选表筛选”，再决定动谁

社区里关于表空洞率自动清理的文章，我觉得最有价值的不是某一条命令，而是它把治理思路做成了“先计算、再判断、后执行”。这个顺序特别对。因为很多表虽然有空洞，但未必值得立刻处理；也有些表空洞率不算夸张，但因为表本身特别大，可释放空间已经很可观了。

### 我自己更常看的几个指标

| 指标 | 我更关心什么 |
|---|---|
| 当前占用空间 | 表现在到底有多大 |
| 有效数据行数 | 不是看总行数，而是看实际还在用的数据 |
| 估算有效空间 | 真正业务数据大概占多少 |
| 可释放空间 | 做完治理大概能回多少 |
| 空洞率 | 现在碎到什么程度 |

### 一个简单的记录表思路

```sql
create table if not exists ops.table_space_check (
  dbname                varchar(128),
  tbname                varchar(128),
  current_disk_size     bigint,
  record_count          bigint,
  calc_disk_size        bigint,
  can_release_disk_size bigint,
  hole_ratio            decimal(10,4),
  check_time            datetime
);
```

配合脚本定时巡检，把候选表先筛出来，再人工确认是否执行。
我自己很喜欢这种思路，因为它把空间治理从“出了问题才临时手工处理”，变成了“可以持续运营的一件事”。

## 七、执行窗口这件事，别等到业务高峰再想起来

GBase 8a 这类表空间整理，真正现场里最容易忽略的不是命令，而是时机。
空洞率治理如果做得太临时，常常会出现两个问题：

- 业务窗口没拿到，执行一半又得停。
- 同时撞上数据同步、导入、报表高峰，系统又被额外拉高。

所以我现在更倾向于把空间治理和跑批窗口一起看，而不是把它当成 DBA 临时单独干的一件事。

### 一个比较常见的 Shell 调度思路

```bash
#!/bin/bash
set -e

gccli -uroot -p'***' &lt;

运维管理

GBase 8a 空洞率治理和历史数据清理

GBase 8a 空洞率治理和历史数据清理

评论

热门帖子