活动专区

活动公告

上车！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 8c 表空间规划和对象迁移

我最近看 GBase 8c 资料时，越来越强烈的一个感觉是：很多现场不是不会建表空间，而是把表空间用得太晚、太散、太随意。

真正落到现场时，最常见的现象通常不是“不会执行 `CREATE TABLESPACE`”，而是业务已经跑了一段时间，默认表空间所在磁盘开始吃紧，热点表、归档表、临时排序、历史索引全堆在一起，最后才想到把对象往别的路径挪。这个时候事情就不再是“加一个目录”这么简单了，而是变成了对象盘点、变更窗口、I/O 冲击、回退方案一起上。

我自己理解下来，GBase 8c 里的表空间更像是**存储布局的控制点**。它能解决“对象落到哪里”的问题，但解决不了“规划混乱”本身。要是前期没想清楚，后面迁移对象时不仅麻烦，还容易把影响面低估。

## 我实际排查时先看的，不是建不建表空间

很多人一上来就问，默认表空间满了，要不要赶紧新建一个。
但我最近整理下来觉得，先别急着建，先把下面几件事想清楚：

1. 这次是容量问题，还是冷热数据混放问题。
2. 需要移动的是表、索引，还是临时文件压力。
3. 这批对象是后续持续新增，还是只需要一次性搬迁。
4. 当前环境是不是适合自定义表空间，而不是继续沿用默认表空间。

先把这四个问题分开，后面的动作才不会乱。

| 现场现象 | 我更倾向于先判断什么 | 常见误区 |
| --- | --- | --- |
| 默认路径空间告急 | 是单个大对象膨胀，还是很多对象混放 | 直接新建表空间，但不盘点对象 |
| 查询高峰时 I/O 抖动明显 | 是热点索引和归档数据抢盘，还是排序临时文件压力 | 只搬表，不搬索引 |
| 新系统即将上线 | 是不是应该在建库建表阶段就定好落盘位置 | 等上线后再慢慢挪 |
| 云化或标准化部署环境 | 是否真的适合使用自定义表空间 | 默认把“多表空间”当最佳实践 |

从落地角度看，表空间最怕的不是没建，而是**只建不用规则、只迁不做分层**。

## 我对 GBase 8c 表空间边界的理解

GBase 8c 的数据最终由 DN 节点落盘，表空间本质上是文件系统里的目录，用来承载数据库对象的数据文件。系统自带的两个表空间是 `pg_default` 和 `pg_global`。我自己更关注的是这两个内置表空间的边界：

- `pg_default`：默认承载非共享系统表、用户表、用户表索引、临时表、临时表索引、内部临时表。
- `pg_global`：承载共享系统表空间，不是业务对象随便放的地方。

我最近看资料时发现，很多人把“表空间”理解成逻辑库的分组，但实际上它更偏**物理存储布局**。数据库、模式、表、索引是逻辑对象；表空间解决的是这些对象最终落在哪个目录、哪类介质上。

| 对象类型 | 我一般怎么理解它和表空间的关系 | 现场建议 |
| --- | --- | --- |
| 数据库 | 可以关联默认表空间，但不是拿来替代对象级规划的 | 库级默认只做兜底，不做精细治理 |
| 表 | 表数据只能属于一个表空间 | 大表、历史表、归档表适合单独规划 |
| 索引 | 索引是独立对象，别默认认为会和表一起迁 | 热点索引要单独盘点 |
| 临时对象/临时文件 | 和会话行为、排序/哈希压力强相关 | 需要单独观察，不要混着看 |
| 系统共享对象 | 走 `pg_global` | 不建议碰业务规划 |

这一点我特别想强调：**迁表不等于迁完了。**
很多现场真正占 I/O 的，可能反而是索引和临时文件。

## 哪些场景适合自定义表空间，哪些场景我反而会克制一点

GBase 8c 文档里对表空间的定位很清楚，核心还是控制磁盘布局、隔离不同对象的存储位置。
但我自己更倾向于把它用在下面几种场景：

| 场景 | 我更推荐的做法 | 原因 |
| --- | --- | --- |
| 热点交易表和历史归档表混在一个路径 | 分开规划业务表空间 | 容量和 I/O 行为差异太大 |
| 热点索引需要更稳定的介质 | 索引与表分开规划 | 真实瓶颈常常先出现在索引读写 |
| 原路径已经接近容量上限 | 给后续新增对象切到新表空间 | 比全量搬迁更稳 |
| 临时排序和业务对象争抢磁盘 | 评估单独的临时表空间策略 | 能减少高峰期互相影响 |

但也不是所有环境都值得自定义表空间。
我最近整理资料时注意到，在一些标准化云场景里，文档本身就不建议用户随意使用自定义表空间。原因也不复杂：底层存储往往已经标准化，额外拆表空间不一定带来收益，反而容易增加运维复杂度。
所以我个人更倾向于这个判断顺序：

- **能用默认表空间解决的，不急着拆。**
- **必须做物理隔离的，再做自定义表空间。**
- **一旦做了，就把对象范围、命名规范、迁移顺序一次想清楚。**

## 我更愿意采用的落地步骤

### 1）先准备目录，而不是先写 SQL

表空间对应的是目录，目录条件不满足，后面 SQL 再漂亮也没用。
我自己一般会先在数据库节点把路径准备好，再进入数据库层动作。

```bash
#!/bin/bash

for p in /data1/gbase/ts_hot \
         /data2/gbase/ts_hist \
         /data3/gbase/ts_temp
do
  mkdir -p "$p"
  chown -R gbase:gbase "$p"
  chmod 700 "$p"
done

# 做变更前，先确认目录为空
for p in /data1/gbase/ts_hot /data2/gbase/ts_hist /data3/gbase/ts_temp
do
  echo "== $p =="
  ls -la "$p"
done
```

这里我一般会特别检查三件事：

| 检查项 | 为什么要先看 | 我自己的判断方式 |
| --- | --- | --- |
| 目录是否已存在且为空 | 表空间创建依赖已有空目录 | 先 `ls -la`，别直接上 SQL |
| 目录属主属组是否正确 | 避免后面出现权限问题 | 统一给数据库运行用户 |
| 路径是否为稳定存储 | 表空间丢失会直接影响实例工作 | 不放移动介质、不放临时挂载点 |

### 2）创建表空间时，先按用途命名

我个人不太喜欢 `space1`、`space2` 这种命名。
真到了半年后排查现场，谁都记不住哪个是热表、哪个是历史、哪个是临时。

```sql
CREATE TABLESPACE ts_hot  LOCATION '/data1/gbase/ts_hot';
CREATE TABLESPACE ts_hist LOCATION '/data2/gbase/ts_hist';
CREATE TABLESPACE ts_temp LOCATION '/data3/gbase/ts_temp';

-- 按需授权给业务角色
GRANT CREATE ON TABLESPACE ts_hot  TO app_rw;
GRANT CREATE ON TABLESPACE ts_hist TO app_rw;
```

命名我一般会直接带语义：

- `ts_hot`：高频交易对象
- `ts_hist`：历史归档对象
- `ts_temp`：临时对象或临时文件策略验证
- `ts_idx_hot`：热点索引单独落盘时再建

### 3）新增对象尽量在创建阶段就落对地方

我自己更倾向于把“对象落盘位置”前移到建表脚本，而不是等上线后再改。
尤其是大表和大索引，后迁移的代价通常更高。

```sql
CREATE TABLE acct.bill_detail (
    bill_id        bigint primary key,
    acct_no        varchar(32) not null,
    trade_date     date not null,
    trade_amount   numeric(18,2) not null,
    status         varchar(16) not null,
    created_time   timestamp not null default current_timestamp
) TABLESPACE ts_hot;

CREATE INDEX idx_bill_detail_01
ON acct.bill_detail(trade_date, acct_no)
TABLESPACE ts_hot;
```

如果某一批对象在一个会话里统一创建，我一般会显式设置默认表空间，避免脚本里漏写：

```sql
SET default_tablespace = ts_hist;

CREATE TABLE acct.bill_detail_2024m12 (
    like acct.bill_detail including defaults
);

CREATE INDEX idx_bill_detail_2024m12_01
ON acct.bill_detail_2024m12(trade_date, acct_no);
```

而临时对象相关的策略，我更愿意单独验证，不和业务表迁移混在一个窗口里：

```sql
SET temp_tablespaces = 'ts_temp';

CREATE TEMP TABLE tmp_bill_check AS
SELECT *
FROM acct.bill_detail
WHERE trade_date >= date '2024-12-01';
```

## 真正开始迁移前，我一定会先做对象盘点

很多人做对象迁移时，最大的问题不是不会写 `ALTER`，而是**不知道自己到底要迁什么**。

我一般先把目标模式里的表和索引盘出来，至少先看清楚当前对象落在哪个表空间。

```sql
SELECT
    n.nspname AS schema_name,
    c.relname AS object_name,
    c.relkind AS object_type,
    COALESCE(t.spcname, 'pg_default') AS tablespace_name
FROM pg_class c
JOIN pg_namespace n
  ON n.oid = c.relnamespace
LEFT JOIN pg_tablespace t
  ON t.oid = c.reltablespace
WHERE n.nspname = 'acct'
  AND c.relkind IN ('r', 'i')
ORDER BY n.nspname, c.relkind, c.relname;
```

如果只是快速查看现有表空间，我一般会直接用这两种方式：

```sql
SELECT spcname FROM pg_tablespace;
```

```sql
\db
```

上面这个顺序我自己很少省。
因为只要一跳过盘点，后面就很容易出现两个问题：

1. 表挪走了，索引还在原路径。
2. 当前对象其实不大，真正大的对象根本没被纳入本次变更。

## 我更喜欢“先生成 SQL，再分批执行”

在现场里，最怕的是手敲几十条 `ALTER TABLE ... SET TABLESPACE`。
我自己的习惯是先生成，再复核，再分批跑。

### 迁移一批历史表

```sql
SELECT format(
    'ALTER TABLE %I.%I SET TABLESPACE ts_hist;',
    schemaname,
    tablename
)
FROM pg_tables
WHERE schemaname = 'acct'
  AND tablename LIKE 'bill_detail_2024%';
```

### 迁移对应索引

```sql
SELECT format(
    'ALTER INDEX %I.%I SET TABLESPACE ts_hist;',
    schemaname,
    indexname
)
FROM pg_indexes
WHERE schemaname = 'acct'
  AND tablename LIKE 'bill_detail_2024%';
```

我个人更倾向于分三步走：

| 步骤 | 我会怎么做 | 这样做的原因 |
| --- | --- | --- |
| 第一步 | 先生成迁移 SQL 清单 | 防止漏对象、漏索引 |
| 第二步 | 先跑小批量对象验证窗口 | 先看锁等待、I/O 波动、耗时 |
| 第三步 | 再分批处理大对象 | 把风险拆小，便于回退 |

这里还有一个我实际排查时经常遇到的坑：
**表迁完以后，不代表业务路径就一定改善。**
如果热点访问主要落在索引，或者高峰期压力来自临时排序，那单纯挪表，效果通常不会特别明显。

## 这些坑我自己会提前写进变更单里

### 坑一：只看表，不看索引

这是最常见的。业务反馈“已经迁表了，磁盘还是忙”，最后一查，大索引还在老路径上。

### 坑二：把表空间当容量回收工具

表空间能重新布局对象，但它不是空间回收工具。
如果问题根源是历史垃圾、对象膨胀、无序增长，只迁路径不治理对象，后面还会再满。

### 坑三：高峰期直接迁大对象

我自己一般不会在业务高峰做大对象迁移。
即使 SQL 看起来简单，底层也涉及真实数据文件移动，这种动作最好还是留给明确的变更窗口。

### 坑四：路径规划没有命名规则

没有命名规范的表空间，时间一长就会变成“知道有、没人敢动”的状态。
后面无论巡检、扩容还是迁移，成本都会升高。

### 坑五：忘了删除前提是表空间必须为空

这类问题通常出现在回滚或者试验环境清理时。
表空间里还有对象，`DROP TABLESPACE` 就不会让你轻松过去。

| 常见坑 | 现场表现 | 我更建议的做法 |
| --- | --- | --- |
| 只迁表不迁索引 | 迁移后 I/O 改善不明显 | 表和索引分开盘点、分开执行 |
| 把表空间当扩容补丁 | 过一段时间又满 | 同时做对象分层和容量治理 |
| 高峰期迁大对象 | 业务抖动、窗口不可控 | 小批量预演后再正式执行 |
| 路径命名混乱 | 后续无人敢维护 | 建立统一命名和用途说明 |
| 清理不彻底 | 删除表空间失败 | 先确认对象完全迁出 |

## 我自己更认可的一套思路

如果把这件事再压缩一下，我现在会把 GBase 8c 表空间治理理解成三句话：

第一，**表空间解决的是物理落盘，不是逻辑建模。**
第二，**新对象尽量创建时就放对位置，别把所有问题留到后迁移。**
第三，**迁移动作一定是对象盘点、表索引分治、分批执行，而不是一条命令糊过去。**

我最近整理下来觉得，GBase 8c 的表空间能力并不难，难的是把它用在真正合适的地方。
该用的时候，要把目录、对象、会话参数、执行窗口一起想清楚；不该用的时候，也别为了“看起来更专业”硬拆出一堆表空间。
真正能让现场更稳的，往往不是多建几个目录，而是从一开始就把对象怎么落、后面怎么迁、出了问题怎么退，提前想明白。

## 参考资料

```text
[1] GBase 8c 文档介绍
https://www.gbase.cn/docs/gbase-8c/%E6%AC%A2%E8%BF%8E/

[2] 基本概念 | GBASE南大通用
https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E5%9F%BA%E6%9C%AC%E6%A6%82%E5%BF%B5

[3] 数据库使用 | GBASE南大通用
https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E6%95%B0%E6%8D%AE%E5%BA%93%E4%BD%BF%E7%94%A8

[4] gsql | GBASE南大通用
https://www.gbase.cn/docs/gbase-8c/04%20%E5%B7%A5%E5%85%B7%E5%8F%82%E8%80%83/01%20%E5%AE%A2%E6%88%B7%E7%AB%AF%E5%B7%A5%E5%85%B7/gsql

[5] GBase 8c 教程（十五）表空间
https://www.gbase.cn/community/post/1821
```





GBase 8c

GBase 8c 表空间规划和对象迁移

GBase 8c 表空间规划和对象迁移

评论

热门帖子