GBase 8a 分区生命周期管理：新增、拆分、归档与删除实战

分区建好之后才是管理工作的开始。随着数据持续写入，分区会填满、需要新增；随着业务增长，原来按月建的分区可能需要拆成按周；历史数据冷却后需要归档或删除。本文系统讲解 GBase 8a 分区的全生命周期管理，覆盖每个操作的语法、执行代价和生产注意事项。

---

一、分区管理的重要性

在生产运行的数据仓库中，分区管理是一项高频且影响深远的运维操作。没有做好分区管理的集群，常见的症状有几种：最大分区（pmax）承载了绝大多数数据，分区裁剪几乎完全失效，所有查询都变成全表扫描；或者因为忘记在数据写入前新增分区，所有新数据都挤进 pmax，导致 pmax 的数据量远超其他分区；再或者历史数据从来不清理，表的分区数量不断增长，元数据查询变慢，规划查询（Planning）的时间占比越来越高。

这些问题的根本原因是把分区当成了一次性的建表配置，而不是需要持续维护的对象。GBase 8a 的分区管理并不复杂，但需要作为常规运维任务纳入日常流程，才能让分区裁剪的性能优势持续发挥作用。

---

二、查看分区现状

在做任何分区管理操作之前，应该先全面了解当前分区的状态：每个分区的数据量、行数、创建时间，以及哪个分区已经接近写满。

-- 查看某张表的所有分区及其数据量
SELECT
    partition_name,
    partition_description,
    table_rows,
    ROUND(data_length / 1073741824, 3)      AS data_gb,
    ROUND(index_length / 1073741824, 3)     AS index_gb,
    create_time
FROM information_schema.partitions
WHERE table_schema = 'sales_db'
  AND table_name   = 'orders'
ORDER BY partition_ordinal_position;

-- 更精确的分区数据量（来自 gclusterdb 系统表）
SELECT
    segment_name,
    partition_name,
    node_name,
    ROUND(SUM(data_size) / 1073741824, 3) AS data_gb,
    SUM(row_count)                         AS row_count
FROM gclusterdb.segment_info
WHERE table_name  = 'orders'
  AND schema_name = 'sales_db'
GROUP BY segment_name, partition_name, node_name
ORDER BY partition_name, node_name;

重点关注两类异常：pmax 分区的数据量是否异常大（说明新数据长期没有对应的明确分区，全部落入兜底分区）；各分区的数据量是否严重不均衡（说明分区粒度设计不合理，某些时间段的数据远多于其他时间段）。

---

三、新增分区

3.1 在 pmax 之前插入新分区

GBase 8a 的 Range 分区要求分区按边界值从小到大排列，pmax（VALUES LESS THAN MAXVALUE）必须始终是最后一个分区。新增分区需要在 pmax 之前插入，使用 REORGANIZE PARTITION 把 pmax 重新组织成"新的具体分区 + 新的 pmax"：

-- 当前表结构（假设 pmax 已经积累了 2025 年的数据）
-- PARTITION pmax VALUES LESS THAN MAXVALUE

-- 新增 2025 年的具体分区，并保留 pmax 继续接收未来数据
ALTER TABLE orders
REORGANIZE PARTITION pmax INTO (
    PARTITION p2025q1 VALUES LESS THAN ('2025-04-01'),
    PARTITION p2025q2 VALUES LESS THAN ('2025-07-01'),
    PARTITION p2025q3 VALUES LESS THAN ('2025-10-01'),
    PARTITION p2025q4 VALUES LESS THAN ('2026-01-01'),
    PARTITION pmax    VALUES LESS THAN MAXVALUE
);

REORGANIZE PARTITION 的执行过程：GBase 8a 会扫描 pmax 中的所有数据，按新的边界值重新分配到各个新分区。这个操作会产生大量 I/O，​执行耗时与 pmax 中积累的数据量成正比​。如果 pmax 中已经积累了 1 亿行数据，REORGANIZE 可能需要数小时。

这也是为什么要提前规划、在数据写入前就把明确分区建好——让数据直接写入正确的分区，而不是先堆在 pmax 再事后整理。pmax 的数据量应该始终接近零，只用于接收极少量还没有对应分区的"未来数据"。

3.2 直接新增不包含数据的分区

如果 pmax 中还没有数据（或数据量极少），可以用更简单的 ADD PARTITION 语法，但前提是 pmax 不存在——因为 ADD PARTITION 会追加到所有分区的末尾，而 pmax 的存在会导致语法冲突。实际上大多数场景都有 pmax，所以 REORGANIZE PARTITION 是更通用的做法。

3.3 自动化预建分区脚本

在生产环境中，手动管理分区容易遗漏。更好的做法是写一个定时脚本，提前几个月批量创建好未来的分区：

#!/bin/bash
# pre_create_partitions.sh：提前 3 个月创建分区，避免数据落入 pmax

DB="sales_db"
TABLE="orders"
GCCLI="gccli -u dba -pdba_password $DB"

# 计算未来 3 个月需要新建的分区
for i in 1 2 3; do
    YEAR=$(date -d "+${i} month" '+%Y')
    MONTH=$(date -d "+${i} month" '+%m')
    PART_NAME="p${YEAR}$(printf '%02d' $MONTH)"
    
    # 分区上界：下月 1 日
    NEXT_MONTH=$(date -d "+$((i+1)) month" '+%Y-%m-01')
    
    # 检查分区是否已存在
    EXISTS=$($GCCLI -e "
        SELECT COUNT(*) FROM information_schema.partitions
        WHERE table_schema='$DB' AND table_name='$TABLE'
          AND partition_name='$PART_NAME'
    " 2>/dev/null | tail -1 | tr -d ' ')
    
    if [ "$EXISTS" -eq 0 ]; then
        echo "创建分区 $PART_NAME (< $NEXT_MONTH)..."
        $GCCLI -e "
            ALTER TABLE $TABLE
            REORGANIZE PARTITION pmax INTO (
                PARTITION $PART_NAME VALUES LESS THAN ('$NEXT_MONTH'),
                PARTITION pmax VALUES LESS THAN MAXVALUE
            );
        "
        echo "分区 $PART_NAME 创建完成"
    else
        echo "分区 $PART_NAME 已存在，跳过"
    fi
done

注册为每月 1 日凌晨执行的 cron 任务，提前把未来 3 个月的分区建好，彻底杜绝数据落入 pmax 的风险。

---

四、删除分区

删除分区是清理历史数据最高效的方式，比 DELETE WHERE order_date < '...' 快几个数量级，因为它直接删除整个数据文件，不产生逐行扫描和删除的 I/O。

-- 删除单个分区（及其全部数据，不可恢复！）
ALTER TABLE orders DROP PARTITION p2022;

-- 确认删除前，先查看分区的数据量
SELECT table_rows, data_length
FROM information_schema.partitions
WHERE table_schema = 'sales_db'
  AND table_name   = 'orders'
  AND partition_name = 'p2022';

删除分区是不可逆操作。在执行前必须确认：该分区的数据是否已经完成归档（导出到离线存储或备份系统）；业务方是否已经确认不再需要这些数据；是否在业务低峰期执行（删除分区会短暂锁表）。

对于需要定期清理历史数据的场景，建议编写专门的分区清理脚本，在执行删除前自动输出待删除分区的数据量，要求人工二次确认，降低误操作风险。

---

五、归档历史分区

生产环境中，历史数据通常不能直接删除，需要先归档（导出到离线存储）再删除。GBase 8a 的分区归档流程如下：

-- 步骤 1：将历史分区数据导出到文件
SELECT *
INTO OUTFILE '/data/archive/orders_2022.csv'
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n'
FROM orders PARTITION (p2022);

# 步骤 2：压缩归档文件（节省存储空间）
gzip /data/archive/orders_2022.csv

# 步骤 3：验证归档文件完整性（对比导出行数与原分区行数）
EXPECTED=$(gccli -e "SELECT table_rows FROM information_schema.partitions \
    WHERE table_schema='sales_db' AND table_name='orders' \
    AND partition_name='p2022'" | tail -1)
    
ACTUAL=$(zcat /data/archive/orders_2022.csv.gz | wc -l)
echo "期望行数: $EXPECTED，实际行数: $ACTUAL"

# 步骤 4：确认完整后删除分区
# gccli -e "ALTER TABLE sales_db.orders DROP PARTITION p2022;"

归档完成后，归档文件应该上传到对象存储或磁带库。如果将来需要查询历史数据，可以把归档文件重新导入到一张专门的"历史查询表"（通常是只读的，不做分区），或者通过 DataX 等工具直接在归档存储上查询。

---

六、拆分分区（粒度细化）

随着数据量增长，原来按季度建的分区可能变得过大，需要拆分成更细的粒度（比如从按季度拆分成按月）。

-- 把 p2024q1（2024年第一季度）拆分为 3 个月度分区
ALTER TABLE orders
REORGANIZE PARTITION p2024q1 INTO (
    PARTITION p2024_01 VALUES LESS THAN ('2024-02-01'),
    PARTITION p2024_02 VALUES LESS THAN ('2024-03-01'),
    PARTITION p2024_03 VALUES LESS THAN ('2024-04-01')
);

拆分操作同样需要重新扫描原分区的所有数据，执行时间与原分区数据量成正比。拆分后，原分区的数据会重新分配到各月度分区，查询中的分区裁剪粒度会变细，查询范围更精确。

---

七、合并分区

与拆分相反，当分区粒度过细（比如历史数据按天建分区，导致分区数量达到数千个），可以把多个小分区合并成一个大分区，减少元数据开销：

-- 把 2020 年全年的月度分区合并成一个年度分区
ALTER TABLE orders
REORGANIZE PARTITION
    p2020_01, p2020_02, p2020_03, p2020_04,
    p2020_05, p2020_06, p2020_07, p2020_08,
    p2020_09, p2020_10, p2020_11, p2020_12
INTO (
    PARTITION p2020 VALUES LESS THAN ('2021-01-01')
);

分区数量过多（超过 500 个）会导致规划查询的时间明显变长，因为优化器需要遍历所有分区来判断哪些需要裁剪。对于很少被查询的历史年份数据，按年合并是一个合理的选择，兼顾了查询分区裁剪的效果和元数据管理的效率。

---

八、分区管理最佳实践

提前规划，永远不让 pmax 积累数据。 pmax 是分区设计的保险，不是常规数据存放的地方。一旦发现 pmax 的数据量开始显著增长，必须立刻安排 REORGANIZE PARTITION 操作，否则拖得越久，REORGANIZE 的代价越大。建议把"检查 pmax 数据量"加入每日巡检脚本，当 pmax 超过一定行数时触发告警。

删除前必须归档，归档后必须验证。 历史数据一旦删除无法恢复，任何情况下都不应该在没有归档确认的情况下执行 DROP PARTITION。验证归档完整性（行数比对是最基本的验证）应该是删除操作的强制前置步骤，不能省略。

所有分区变更操作都在低峰期执行。 REORGANIZE 和合并操作会产生大量 I/O 并短暂锁定目标分区，对正在查询该分区的业务会有影响。对于 7×24 小时的业务系统，分区管理窗口需要提前与业务方协商，选择查询量最低的时间段执行。

控制分区总数在合理范围内。 根据实际测试经验，GBase 8a 集群的单表分区数超过 200 个后，规划查询时间会明显增加；超过 1000 个后，部分管理操作的响应时间会变得很长。对于长期运行的数据仓库，需要定期评估是否应该将极老的历史分区合并或归档删除，把活跃分区数控制在合理范围内。