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

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

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

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

不考虑使用 datax 吗？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一年也才一个亿 分啥

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

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

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

按 uid hash 分库分表，将这个 hash 值塞到 order_id 里，这样既能通过 uid 从一个表找到用户的所有订单，又能通过 order_id 找到对应的表。至于已经存在的历史 order ，因为改 order_id 使其符合新规则可能有隐患，建议不迁移，这样一个用户最多查一次新表一次旧表就能找出所有订单，旧表没有新记录写入也不用担心性能下降，而且订单是有时效的，过段时间还能直接干掉旧表。

@gam2046 用 brin 索引试试呢

新数据双写，历史数据迁移或归档

没多少数据直接 sql 插入。还是需要不停机维护？

分表分库注定要被淘汰，建议选择云数据库、分布式数据库。

@phx13ye
不停机归档，有没有方案？

@kanepan19 没做过太高大上的，
1select 源库数据，插入归档库，两边校验，delete 源数据库历史数据， 对源表做一下 alter table tb_123 engine=innodb ，释放空间

最后两步可选