You need to enable JavaScript to run this app.
最新活动
大模型
产品
解决方案
定价
生态与合作
支持与服务
开发者
了解我们

MySQL无/低停机时间重分区表的方法咨询

MySQL无/低停机重分区方案

好问题!MySQL确实支持多种低停机甚至无停机的分区调整方案,完全可以替代你之前的停机导出重建流程,下面分场景给你详细说明:

一、给现有分区表新增分区(最常见场景)

如果你的表已经是分区表(比如RANGE、LIST类型),只是需要新增分区来分片,直接用ALTER TABLE ADD PARTITION命令即可,MySQL 5.6及以上版本支持该操作的在线执行,只会在操作的最后阶段有极短的锁表时间,几乎不影响业务读写。

举个RANGE分区的例子(按日期分区):
假设现有表orders的分区定义是到2023年12月31日:

CREATE TABLE orders (
    id INT,
    order_date DATE
)
PARTITION BY RANGE (TO_DAYS(order_date)) (
    PARTITION p202301 VALUES LESS THAN (TO_DAYS('2023-02-01')),
    ...
    PARTITION p202312 VALUES LESS THAN (TO_DAYS('2024-01-01'))
);

现在要新增2024年上半年的分区,执行:

ALTER TABLE orders
ADD PARTITION (
    PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')),
    PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')),
    ...
    PARTITION p202406 VALUES LESS THAN (TO_DAYS('2024-07-01'))
);

这个操作后台会异步完成分区的创建,期间业务可以正常读写,只有在最后元数据更新时会有毫秒级的锁表,完全可以接受。

二、拆分现有大分区(重分区需求)

如果需要把一个已有的大分区拆分成多个小分区,用ALTER TABLE REORGANIZE PARTITION命令,同样支持在线执行,几乎无停机。

比如把p2023这个大分区拆成四个季度分区:

ALTER TABLE orders
REORGANIZE PARTITION p2023 INTO (
    PARTITION p2023q1 VALUES LESS THAN (TO_DAYS('2023-04-01')),
    PARTITION p2023q2 VALUES LESS THAN (TO_DAYS('2023-07-01')),
    PARTITION p2023q3 VALUES LESS THAN (TO_DAYS('2023-10-01')),
    PARTITION p2023q4 VALUES LESS THAN (TO_DAYS('2024-01-01'))
);

这个操作的原理是后台复制分区内的数据到新分区,期间原分区依然可以正常读写,复制完成后会瞬间切换分区映射,几乎不会有业务中断。

三、非分区表转分区表(进阶场景)

如果你的表还不是分区表,直接用ALTER TABLE ... PARTITION BY ...可能会锁表较长时间(取决于表大小),这时可以用第三方在线DDL工具来实现无停机转分区:

  • pt-online-schema-change(Percona工具):后台创建临时分区表,逐步复制数据,最后替换原表,全程不锁原表。
  • gh-ost(GitHub开源工具):原理类似,通过二进制日志同步数据,更轻量,对资源占用更低。

比如用pt-online-schema-change的示例命令:

pt-online-schema-change \
  --alter "PARTITION BY RANGE (TO_DAYS(order_date)) (
    PARTITION p2023q1 VALUES LESS THAN (TO_DAYS('2023-04-01')),
    PARTITION p2023q2 VALUES LESS THAN (TO_DAYS('2023-07-01')),
    ...
  )" \
  D=db,t=orders \
  --execute

四、关键注意事项

  • 操作前务必备份数据:虽然这些操作都是安全的,但以防意外(比如磁盘空间不足、网络中断),备份是底线。
  • 监控操作进度:可以用SHOW PROCESSLIST或者查询INFORMATION_SCHEMA.PROCESSLIST查看DDL操作的状态。
  • 资源监控:对于超大表(比如几十上百G),在线DDL会占用一定的磁盘IO和CPU,建议在业务低峰期执行。
  • 版本兼容性:确保你的MySQL版本是5.6+,更早的版本在线DDL支持有限,可能需要升级。

总结

无论是新增分区、拆分现有分区,还是从非分区表转分区表,都有成熟的低/无停机方案,完全可以替代你之前的停机导出重建流程,大大减少业务中断时间。

内容的提问来源于stack exchange,提问作者Helmut Januschka

火山引擎 最新活动