【转载“GBase 8a数据库”公众号】GBase 8a 数据库磁盘空间使用率过高的优化解决方案

背景

不少线上 GBase 8a 集群常会遇到节点磁盘使用率飙升至 95% 以上的告警，严重时会阻塞写入、影响业务正常运行。深究根源主要有三点：

1. 数据库默认压缩等级偏低，数据存储体积大
2. 大量删除、更新操作产生磁盘空洞，物理磁盘被无效占用
3. 未适配业务数据选型最优压缩算法，存储空间持续浪费

今天分享两套解决方案：一套​零硬件投入、从存量数据压缩 + 碎片清理入手，最大化节省磁盘​，一套硬件扩容兜底，兼顾短期应急与长期业务发展。

---

优化方案：表压缩 + 空洞清理优化

无需新增服务器，仅通过调整数据库压缩策略、回收磁盘空洞，就能大幅释放存储空间，分为「在线渐进优化」「离线一次性深度压缩」两种落地方式。

优化前必做两项巡检

01 查看全局压缩配置

执行 SQL 查看集群默认压缩参数：

SHOW VARIABLES LIKE '%compress%';

gbase>
gbase> show variables like '%compress%'
    -> ;
+----------------------------------+-----------------+
| Variable_name                    | Value           |
+----------------------------------+-----------------+
| _gbase_delete_filter_compressed  | OFF             |
| _gbase_tx_log_compress           | ON              |
| gbase_compress_level             | 0               |
| gbase_compress_method            | NO Setting      |
| gbase_compression_num_method     | 5               |
| gbase_compression_sampling       | 1               |
| gbase_compression_str_method     | 5               |
| have_compress                    | YES             |
| slave_compressed_protocol        | OFF             |
+----------------------------------+-----------------+
9rows in set (Elapsed:00:00:00.00)

所查询结果可见默认参数 gbase_compress_level=0，属于轻量级压缩，压缩倍率有限，磁盘占用有极大优化空间。

提示： 高压缩算法会小幅增加 CPU 计算开销，建议避开业务高峰操作。

02 检查表空洞率

数据表经过频繁 DELETE、UPDATE 后，会产生大量磁盘空洞，文件实际占用磁盘远大于真实有效数据。我们可以通过 SQL 批量统计全库表空洞占用：

USE performance_schema;

SELECT TABLE_SCHEMA, TABLE_NAME, DELETE_ROWS, TABLE_ROWS, DELETE_RATIO 
FROM TABLES
WHERE table_schema='数据库名' AND table_name='表名';

• 空洞率 > 20%：优先清理碎片，可快速回收大量闲置磁盘
• 空洞率 < 10%：直接推进压缩优化即可

方案 1：在线渐进式压缩（业务无中断，线上首选）

不用重建全表、无需停机，通过 ALTER TABLE 修改表压缩配置，存量旧数据不会立刻重压缩，新写入、更新、滚动淘汰的数据会自动采用高压缩策略，磁盘空间随业务数据迭代逐步释放，无大批量 IO 冲击线上业务。

压缩算法选择

算法	特点	压缩率	性能
Nozip	无压缩	~0%	最快
HighZ	高压缩比	25%-26%（随机）/ 99%（重复）	最差
RapidZ	快速压缩	5%-7%（随机）/ 99%（重复）	接近默认
NewRapidZ	RapidZ 增强版	5%-7%（随机）/ 99%（重复）	接近默认
STDZ	标准压缩	50%-52%（随机）/ 99%（重复）	推荐

在线修改压缩语法

ALTER TABLE t1 ALTER COMPRESS('STDZ', 0);

• 第一个参数：指定压缩算法
• 第二个参数：压缩级别（0-9），0 压缩比最低但速度最快，9 反之
• 不设置时 show variables 显示为 0。 默认级别为 0，针对不同的原型算法有不同的选取。

快速清理空洞碎片

若检查表空洞率较高，搭配碎片整理语句，立刻回收空洞占用磁盘：

按文件级回收（效率较高）：

ALTER TABLE table_name SHRINK SPACE;

按行级回收（完全保证有效行原始顺序，效率较低）：

ALTER TABLE table_name SHRINK SPACE FULL;

注意事项：

• 执行 Shrink Space 时会锁表，长时间阻塞查询
• 只有数据文件中的所有数据都被删除后，该文件才会被释放
• 最少要保留一个 seg 文件，不会全部删除

方案 2：离线重建高压缩表（一次性释放 50% 磁盘空间）

适合历史归档表、低频查询、无实时写入的数据表，全量重建高压缩表可一次性最大化瘦身，预估释放近一半存储空间。

01 创建高压缩新表

CREATE TABLE t1_bak (
    a int(11) DEFAULT NULL,
    b varchar(10) DEFAULT NULL
) COMPRESS('HighZ', 0)
ENGINE=EXPRESS DEFAULT CHARSET=utf8 TABLESPACE='sys_tablespace';

02 全量迁移历史数据

INSERT INTO t1_bak SELECT * FROM t1;

03 数据校验并替换原表

核对数据行数、关键字段，确认数据完整无误后切换表：

DROP TABLE t1;
RENAME TABLE t1_bak TO t1;

04 验证磁盘释放效果

库内查看表存储大小：

SELECT table_name, data_length/1024/1024 AS table_size_mb 
FROM information_schema.cluster_tables 
WHERE table_schema = '数据库名' AND table_name='表名';

服务器侧查看磁盘整体占用：

df -h

压缩优化注意事项

1. 高压缩会增加 CPU 解压开销，高并发实时业务优先使用「在线 ALTER 渐进压缩」
2. 全表重建、碎片整理操作务必安排在夜间业务低峰窗口
3. 统一使用 level=0 自动适配模式，避免手动设置过高压缩等级引发查询卡顿

---

硬件扩容方案（长期海量数据最优解）

如果业务数据持续高速增长、并发读写压力大，无法承受压缩带来的 CPU 损耗，服务器扩容是根治存储瓶颈的方案。

实施流程

步骤	操作
资源申请	提交服务器扩容申请，明确配置要求（CPU、内存、磁盘类型及容量、网络带宽等）
集群纳管部署	新服务器安装部署 GBase 8a，同步集群配置，打通节点网络
数据均衡分流	通过扩容新节点、数据重分布等方式，将大表数据分摊至新节点，均衡全集群磁盘负载

方案优势

从硬件层面扩充存储上限，完全无压缩带来的性能损耗，适配长期海量数据增长、高性能核心业务场景。

---

两大方案对比与落地优先级建议

方案	核心优势	存在短板	适用场景	磁盘节省效果
在线 ALTER 渐进压缩	业务零中断、零硬件成本、自动迭代瘦身	空间释放速度较慢，依赖数据自然淘汰	线上高并发实时业务、不允许停机	中等，长期持续释放
离线重建高压缩表	一次性大幅释放磁盘（约 50%），同步清理空洞	需夜间低峰操作，全量拷贝消耗 IO	历史归档、日志流水、低频查询表	极高，短期快速缓解
服务器扩容	彻底解决存储瓶颈，不影响数据库性能	硬件采购、部署周期长，存在资金成本	长期海量增量、高并发核心业务	无存量释放，新增容量

落地执行优先级

1. 紧急告警场景（磁盘使用率 95% 高危）
   • 先批量查询空洞率，空洞率超 20% 的表执行 ALTER TABLE table_name SHRINK SPACE FULL 快速回收碎片
   • 再对大表执行在线渐进压缩，无需停机即可遏制磁盘持续上涨
2. 归档、日志类静态数据表
   • 业务低峰窗口执行离线重建高压缩表，一次性释放大量磁盘空间
3. 长期高增长核心业务
   • 直接走服务器扩容流程，从硬件层面解决存储上限问题

---

磁盘运维小规范，规避爆满告警

1. 每月定期巡检全表空洞率，集中清理空洞率超 20% 的数据表
2. 针对不同的表指定合理的压缩算法，从源头控制磁盘占用
3. 标准化使用 level=0，不手动固定高压缩档位
4. 磁盘使用率预警阈值设置 85%，提前开展碎片清理、压缩优化，避免触及 95% 高危水位