求教个 Mysql 数据库分库分表的问题

[Laysan]

有个表 biz_order 是单表的，目前已经 600W+数据，每日还在 30w 增长量

考虑把 biz_order 表分库分表，分成 10 库 100 表，根据 order_id hash 计算分表位

现在的问题是创建好表了，旧数据如何快速迁移到新的分表里面

用存储过程能快速迁移么？还是要写代码慢慢查询再插入？

[plutome]

600W 而已。insert into select xxxxx 也花不了多久。

[qizheng22]

shardingjdbc 分库分表，不是有个 sharding-ui 和 sharding-proxy 。
shardingproxy 相当一个中单件，用 mysql 客户端连接，再导入。
仅用 order_id 的 hash 分表，以后表不够，再扩展就麻烦了

[dusu]

按 1kw 分一次表 上线后等 id 满了切就行
不用考虑这次迁移 一个表不差几百 w
与其考虑迁移 不如多考虑分表后的数据聚合问题吧

[yungeo]

不考虑使用 datax 吗？

[declandragon]

写个小脚本，多线程分段处理数据很快的，我也是 3 楼的想法，聚合怎么办

[T0m008]

订单表难道不是把旧日期的分出去吗，过时的订单能有多少流量？

[wqhui]

不理解怎么会想要分 100 个表存储，有没想过如果查询条件里面没有带上分表键需要所有表扫一次，应该是把冷数据归档掉，分表只存热数据。除非规定每个查询一定要带分表键，或者把这些数据同步到别的组件比如 es 上

[Granado]

说下我的想法吧：
如果是有明显时间冷热的数据，建议的做法是定期归档然后，删除历史数据，查历史数据的时候就查归档。当然这么做也需要有一定的基建后比较轻松。

如果采用分表，以后非分表维度的查询（例如你文中提到的 order_id 分表，查询的时候需要查用户的订单，查询维度是 user_id ）就会比较麻烦，要构建单独的查询索引（例如前面提到的 user_id ---> order_ids 的映射），这时候又会有额外的维护（索引维护，数据一致性问题，延迟问题）。

这时候我建议还是直接上 tidb 这种天然支持分表的，维护成本低很多，相对来说迁移也比较好迁移，前期数据量低可以停机迁移，数据量大先双写单读，再单写单读就好。

[me1onsoda]

2023 年还有人分库分表吗?这方案还是建立在以前 hhd 低速存储的前提下，以后 ssd 都比 hhd 便宜，速度再提升，要进历史的垃圾桶吧？

[james2013]

我觉得分库没有必要,直接在 1 个库里分 100 张表,使用和维护比较方便
存放分表数据采用代码提供的唯一的 id,然后使用代码分批插入,比如每次 3000 条

[kanepan19]

那个是怎么说来着， 分表分库是解决插入问题的。

[kanepan19]

接上面，分表分库是解决 插入性能不足问题的。
查询性能不行，加读库 或 olap

[lsk569937453]

自己写程序迁移，有唯一 id 的好迁移。

[dw2693734d]

@me1onsoda 2023 年了，还有人不知道 shard 是很多公司（包括谷歌, 微软）在数据库管理中常用的技术吗？通过将数据分割成较小的部分，可以提高数据库的性能和可扩展性。

[dw2693734d]

说到分库分表 shard ，就不得不提一下 postgres 了，使用 citus 插件，一键分表，自动计算 hash

<amp-youtube data-videoid="JwjjUT8K7po" layout="responsive" width="480" height="270"></amp-youtube>

[me1onsoda]

@dw2693734d 你别光说好处，代价呢？

[dw2693734d]

@me1onsoda 用空间换时间，本来就是互联网公司常用的技术。缓存不也是一样的道理。

[dailiha01sy]

一年也才一个亿 分啥

[gam2046]

@dw2693734d #14 大佬，现在我正好遇到一个问题，现在有一个 postgres 表，存在一个 timestamp 类型的字段，而这个字段又是索引字段，很多地方需要通过这个来作为查询条件。同时这个字段更新又非常频繁，导致索引也需要频繁更新，进而导致 IO 性能低下。

针对这种场景，有什么优化建议嘛，目前索引类型是 btree

[poembre]

我有个单表表 目前 7 亿+ 数据量, 一周差不多 2-3KW 写入量。