oceanbase表分区变更流程(从8到10)

表分区增加从8到10的流程

适用场景：OceanBase MySQL 兼容模式，将 orders 表从 HASH(id) 的 8 个一级分区调整为 10 个一级分区。

本文是实施流程，不是已在目标实例验证的执行脚本。OceanBase 版本、表结构和重分区能力尚未核验；所有变更必须先经过版本核对与测试。

不适用于 RANGE 分区新增月份、子分区调整，也不代表修改 MySQL 原生分区表的通用步骤。

1. 核心结论

在目标版本支持该 HASH 重分区操作、且操作成功完成的前提下，数据库会按照新的 10 分区规则重新组织历史数据。应用不需要逐条搬迁记录。

变更前
应用访问 orders
    └── 历史数据按 HASH(id) 的 8 分区规则分布

执行受支持的重分区操作
    └── 数据库按新的分区规则处理已有数据及相关索引

变更成功后
应用仍访问 orders
    └── 历史数据与后续新增数据统一使用 10 分区规则

需要区分以下几点：

• 不是保留原来的 8 个分区不动，再增加两个只接收新数据的空分区。
• 历史记录的目标分区可能变化，但不能断言每条记录都一定换分区。
• 重分区本身不应改变主键值或业务字段，也不应该改变原有约束的业务语义。
• 可能涉及大量数据重写、索引处理和额外空间，不是只修改元数据中的数字。
• 内部复制、切换和并发写入处理方式取决于版本，不应假定所有版本采用相同实现。
• 10 个分区不是 10 个 Zone、10 个副本或 10 台机器，也不保证性能一定提高。

2. 第一步：确认为什么要增加分区

先明确目标和可度量的验收指标，再决定是否从 8 调整到 10。

现象或目标	需要先确认
个别分区负载过高	是数据倾斜、热点键，还是整体资源不足；多两个分区未必能解决热点键
新增了物理节点，希望分散数据	现有 8 个分区是否已足够分布，租户是否能使用新增资源
单分区数据量过大	增加到 10 后的实际容量收益是否足够
查询慢	是否由索引、扫描量、远程访问或执行计划导致
宿主机内存或磁盘不足	增加分区不增加物理资源，且变更期间可能需要更多空间

对当前同一宿主机运行三个 observer 的部署，分区数增加不会带来新的物理 CPU、内存或磁盘容量。

记录变更前基线：数据规模、分区大小及负载分布、核心 SQL 延迟、吞吐、租户资源、磁盘余量和副本健康状态。

3. 第二步：核验版本、表结构与分区

在目标业务租户、目标数据库内执行只读检查：

SELECT VERSION();

SELECT DATABASE();

SHOW CREATE TABLE orders;

SHOW INDEX FROM orders;

VERSION() 的输出应结合部署信息确认 OceanBase 的完整版本和构建信息，不要只根据 MySQL 兼容版本号判断能力。

查看分区元数据：

SELECT
    TABLE_NAME,
    PARTITION_NAME,
    PARTITION_ORDINAL_POSITION,
    PARTITION_METHOD,
    PARTITION_EXPRESSION,
    SUBPARTITION_NAME
FROM information_schema.PARTITIONS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders'
ORDER BY PARTITION_ORDINAL_POSITION;

确认当前确实为：

PARTITION BY HASH (id)
PARTITIONS 8

然后按目标版本的官方文档核验：

• 是否支持现有 HASH 分区表从 8 个分区直接重分区为 10 个。
• 支持的准确 SQL 语法，以及在线执行和并发 DML 的限制。
• 主键、局部或全局索引、唯一约束、外键及其他实际对象是否限制该操作。
• 是否存在 DDL 超时、空间、资源或与其他任务并行执行的限制。
• 官方支持的进度查看、失败排查和取消方式。

核验未通过时，不执行直接重分区 SQL，进入第 8 节的迁移方案。

4. 第三步：测试与变更准备

1. 在相同 OceanBase 版本的测试环境复现表结构，使用接近生产的数据规模和分布。
2. 演练重分区，测量耗时、额外磁盘需求、CPU、I/O、日志开销和业务延迟。
3. 验证变更期间的 INSERT、UPDATE、DELETE，以及应用面对等待、超时和连接中断的行为。
4. 检查应用是否显式指定分区名、依赖分区名称或数量；如存在，提前制定适配方案。
5. 确认备份可用并验证恢复路径。多副本不等于备份。
6. 选择低峰窗口，定义监控指标、停止条件、负责人和故障处理方式。

停止条件应由实测与业务 SLO 决定，例如可用空间跌破已批准的安全余量，或核心请求延迟持续超标。不要在未知内部状态时直接杀 observer、反复提交 DDL 或清理数据库文件。

5. 第四步：执行重分区

仅在目标版本文档和测试均确认支持后，才使用经核验的语句。以下是待核验的语法形式，不是对所有 OceanBase 版本的兼容性承诺：

ALTER TABLE orders
PARTITION BY HASH (id)
PARTITIONS 10;

执行要求：

• 再次确认连接的租户和数据库正确，并记录变更开始时间。
• 使用目标版本允许的 DDL 超时和执行方式，不直接照搬 MySQL 参数。
• 避免同时进行该表的其他结构变更或未经评估的高负载任务。
• 按版本支持的方法监控 DDL 状态、租户资源、磁盘、日志和业务错误率。
• 客户端超时或断连后，先核对服务端任务和表结构状态，不立即重试。

"在线 DDL"不等于零影响；准备或切换阶段可能出现等待，数据处理期间也可能影响业务性能。具体行为以目标版本和演练结果为准。

6. 第五步：完成后验证

6.1 确认分区结构

SHOW CREATE TABLE orders;

SELECT COUNT(DISTINCT PARTITION_NAME) AS partition_count
FROM information_schema.PARTITIONS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders';

在本文限定的一级分区场景中，应确认分区规则仍为 HASH(id)，一级分区数量为 10。同时查看完整分区列表，不依赖固定的分区名称推断结果。

6.2 验证数据和约束

• 核对主键、唯一约束、索引、默认值及自增属性是否保持预期。
• 抽查多个历史 ID，对比关键业务字段，并验证新记录写入与读取。
• 根据数据规模执行分段校验、业务汇总核对或经过验证的校验工具。
• 需要精确前后对比时，使用明确的停写边界，或可追踪增量的一致性校验方案。

并发写入期间，两次独立执行 COUNT(*) 的结果不同，不一定表示数据丢失；行数相同也不能证明全部内容一致。元数据中的行数或大小统计也不能当作精确一致性证据。

6.3 验证性能与分布

• 复测按 ID 点查、批量查询、分页、统计、JOIN 及主要写入事务。
• 检查执行计划、扫描量、索引使用、分区裁剪和远程操作。
• 检查分区的实际节点分布、数据倾斜、副本健康和租户资源。
• 对比变更前后的吞吐和 P95/P99 延迟，覆盖有代表性的负载时段。

WHERE id = ? 可以根据 HASH 分区规则定位相关分区；WHERE id > ? 通常不能据此只访问单个 HASH 分区。分区增加后，跨分区查询的协调成本也可能增加。

7. 异常处理与回退

情况	处理原则
SQL 报不支持或结构限制	停止尝试，核对版本和限制，评估新表迁移
客户端超时或断连	查询服务端 DDL 状态和实际表结构，避免重复提交
资源或延迟超过阈值	按演练过的流程处理；是否取消、如何取消以版本支持为准
DDL 失败	确认表可用性、结构、任务和数据状态，不假定一切已自动恢复
成功后性能退化	检查统计信息、执行计划、数据布局和资源，不直接归因于分区数

把 10 改回 8 是另一次重分区，不是即时回滚按钮。 不要依赖普通业务事务的 ROLLBACK 撤销这类 DDL。备份恢复也需要评估停机、恢复时间和变更后写入的保留方式。

8. 不支持直接重分区时：新表迁移

替代流程如下：

原表 orders：8 分区
        ↓
创建 orders_new：10 分区，保留所需业务约束和属性
        ↓
建立一致的历史数据复制与增量衔接边界
        ↓
搬迁历史数据，持续追平期间产生的变更
        ↓
校验数据、索引、权限、依赖及应用行为
        ↓
按计划暂停或控制写入，追平增量并切换
        ↓
观察验证，按保留策略处理旧表

此方案中，旧表数据不会因为新表是 10 分区而自动进入新表，需要单独迁移。

实施前必须确定所选工具支持当前源端、目标端和同租户或跨租户布局。不能默认某个 CDC 或迁移工具支持任意表到表复制。

注意事项：

• 并发写入时，不能只做一次 INSERT ... SELECT 就切换；还必须处理新增、更新和删除。
• 只有明确允许全程停写并验证容量、事务成本时，才考虑简化为停写复制方案。
• 新表必须保留预期的字段、约束、索引、默认值、权限及相关依赖；迁移后验证自增生成行为。
• 切换方式需核对当前版本的重命名能力、依赖对象及原子性，不能默认两次改名就安全。
• 保留旧表不等于具备完整回退能力。切换后产生的新写入如何返回旧表，必须提前设计。

9. 验收清单

• 已确认源表为本文限定的 HASH 一级分区表，并核对目标版本支持情况。
• 已证明 8 改 10 对目标问题有帮助，且资源余量满足演练结果。
• 已完成备份和恢复准备，确定变更窗口、停止条件及异常处理流程。
• 服务端 DDL 已明确成功完成，表结构显示 10 个分区。
• 历史数据、新写入、约束和索引行为验证通过。
• 核心 SQL、吞吐、延迟和副本健康达到验收标准。
• 已记录变更结果、执行时间、资源峰值及后续观察结论。

10. 总结

受支持的 HASH 重分区成功后，历史数据会由数据库按照新规则重新组织；不需要应用逐条重插。操作是否可直接执行、是否在线、需要多少资源，必须结合目标 OceanBase 版本、表结构和实测确认。

官方资料入口：https://www.oceanbase.com/docs。请选择实际部署版本，查阅分区变更、ALTER TABLE 限制、DDL 管理、备份恢复和迁移相关说明。