超一亿行的大表，如何给拆分成分区表

应用开发者专区
#1

目前3.2.3集群分布式ob-mysql数据库，有些业务是超一亿行的大表，如何给拆分成分区表

#2
    1. 选择什么分区键取决于业务读和更新这个分区表的方式（也就是SQL），并结合分区表的功能选择。
    1. OB 3.2 不支持非分区表变分区表，所以得变相实现，类似以前 MySQL 5.5 不支持 ONLINE DDL 时 一些外部工具的实现方式：搞个临时表，然后数据同步过去，然后改表名。

在 OB 3.2 里非分区表变分区表思路也是如此。

  • 如果业务能停止读写，直接建新的分区表，然后用 INSERT INTO SELECT FROM 语句分批并行将老表数据写入到新表。为了性能最好，分区表不要带索引（主键要提前建好，主键包含分区键），并且分区表的 PRIMARY_ZONE 设置为跟老表同一个 ZONE 。如果租户的 UNIT_NUM 为 2 ，这个性能可能也不好。做完后，老表和新表交换名字。
  • 如果业务不能停止读写，那就使用 OMS 单独迁移老表数据到新表里（OMS 同步表时改一下映射的表名），并开启增量同步。到最后数据同步快赶上的时候，业务写短暂停一下。然后快速的将老表和新表换个名字。
  • 最后补上分区表的索引，注意尽可能是 LOCAL 索引。
3 个赞
#3

我们的租户的UNIT_NUM 为 2，根据业务选择Range分区或LIST分区一级分区，该划分多少分区数？

#4

如果是 list 分区说明有固定的列表值了，这个分区数好确定，尽可能维持分区大小均衡。如果是 range 分区的话，看是什么 range 了。如果是时间，分区数没有限制，可以一直加，只有范围粒度原则问题。

由于你还是没有描述业务，所以这个问题不会有具体的答案。

2 个赞
#5

具体分区数评估下业务，比如要用range分区，业务如果查最近一个月或者最近一年的数据哪就直接实现就可以，不用去关注分区数了