15 | MySQL存储海量数据的最后一招：分库分表
该思维导图由 AI 生成，仅供参考
如何规划分库分表？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
MySQL存储海量数据的挑战在于高并发和性能限制，而分库分表成为解决方案。在规划分库分表时，需考虑分库分表数量和选择Sharding Key，以满足查询需求。实施分库分表需谨慎，因其限制数据库查询能力，可能需将数据同步到其他存储系统。分库分表被视为解决数据量和并发问题的最后一招。常用的分片算法包括范围分片、哈希分片和查表法，各有优劣。对于订单表的分库分表，一般按用户ID作为Sharding Key，采用哈希分片算法。此外，分片相关知识适用于其他分布式数据库，原理通用。思考题则提出了关于外键关联表的处理。文章内容涵盖了分库分表的规划、实施和分片算法选择，对读者快速了解该主题具有指导意义。
《后端存储实战课》，新⼈⾸单¥59
全部留言(49)
- 最新
- 精选
李玥置顶Hi，我是李玥。 这里回顾一下上节课的思考题： 在数据持续增长的过程中，今天介绍的这种“归档历史订单”的数据拆分方法，和直接进行分库分表相比，比如说按照订单创建时间，自动拆分成每个月一张表，两种方法各有什么优点和缺点？欢迎你在留言区与我讨论。 这个问题我在本节课中也提到了，简单的总结一下。按月自动拆分订单的好处是，不需要做数据搬运，相对实现比较简单，数据分得更碎，缺点是跨月查询比较麻烦，但好处是容量也更大（因为分片更多）。归档历史订单的方法，实现起来更复杂，容量要小一些，但是对查询更加友好。2020-04-0125
leslie是不是漏了另外一种拆分方式：纵向拆分？分表应当还有一个原因，早期数据量小可以几十个字段都没有关系；后期数据量大了，多列查询导致了一些性能问题。我自己在生产中就碰到了设计的不合理性，做了纵向分表-效果还不错，精度只能靠实战、学习、反思去提升。 课程中提及的分表所引发的外键问题其实应当和DML有关：查询并无影响。个人觉得影响不大，细看是多张表，但是设计时其实还是一张；查询时对应的判断补进去就好。作者回复: 👍👍👍
2020-04-02237
百威接“发条橙子”“用完整用户id分片还是后四位分片”对话：为什么是一样的啊，没懂……比如300个分片，用取模法，用户id分别为12000和22000，后四位相同但查找的表不同呀……我感觉这块没说清楚，我听完之后也有这个疑惑作者回复: 这个地方详细说一下，比如只取用户ID后四位，为了保证后四位的哈希结果和完整用户ID的哈希结果是一样的，分片的数量需要能被10000整除。300个分片是不行的，200、250这种分片数量就是可以满足要求的。
2020-04-13728
sami感觉Redis Cluster的分片规则有点像查表法作者回复: 你说的没错！
2020-03-3124
Mq关联表可以冗余用户ID字段，跟订单表的都在一个库里吗，这样用户维度的交易都在一个库事物里面，大部分的关联查询也是在一个库里。 老师查找法有具体例子吗，我们之前也有过表按hash分后数据极度不均作者回复: 查表法一般可以配合哈希或者范围分片一起使用。 比如说，我们按用户ID哈希分成10个分片，其中第8个分片数据特别多不均匀。 那我们可以按用户ID哈希成100个逻辑分片。 再做一个100逻辑分片和10个物理分片的映射表，这个表里面只有100条记录。 那怎么来映射我们就可以人工分配，让10个物理分片中的数据尽量均匀。
2020-03-31316
Loren老师，请教一个问题，分库分表以后，数据量大的情况下，分页一般该怎么处理？我暂时没这方面的经验，想了解一下作者回复: 如果需要分库分表还要跨表查询，这种情况下没有什么好的分页解决方案，业务还是要规避分库分表之后跨表查询的情况。 如果实在规避不了，就要考虑sharding key是不是合理，或者可能要更换数据库。
2020-04-04613
锐请问老师，假设现在是24个分片，使用取模算法，后续发现分片后数据量还是太大，要改成扩大分片数，需要重新迁移数据吧？工作量大且复杂，该怎么设计比较方便扩容呢作者回复: 比较方便的方法是扩容后的分片数量是24的整数倍，这样每个分片相当于1分n。或者在设计之初就采用一致性哈希算法来分片。
2020-04-1911- 饭团老师您好，您提到的把用户id放到订单id中，是说如果用订单id去做查询，就把第10-14位取出来，之后再用这部分去查询是吗？
作者回复: 是的
2020-03-31178 
Echo老师您好：您文中说“范围分片特别适合那种数据量非常大，但并发访问量不大的 ToB 系统”，如果是这样的话 并发量不大的ToB 系统就没必要分库了吧？因为分库要解决的是高并发的问题。可以用分表或者归档的方式解决？作者回复: 是这样的。
2020-05-167
曙光老师，我有个生产问题，内部管理系统，使用的是Oracle数据库，按月分表，该表每天新增近6W的数据，目前共有1亿的数据量。现在的问题是，业务每天都需要查这个表进行对账，查询速度很慢，每次慢的适合，我们就重建索引速度就快一点，过一段时间又会变慢。最要命的事，这些数据有一个归属人的字段，如果某个人换部门或离职，这部分历史数据都要归宿新人，涉及历史数据的修改。 之前通过归档历史表，处理查询慢的问题，发现还没重建索引收益高，就没修改了。但是交易归属人就比较麻烦，一次变更需要2～3分钟，体验很差。我目前想的解决方案是：重构历史功能，将交易表拆分成两张表，账户表，交易余额对账表和人员归属表，虽然每天6w笔数据，但大部分账户是一样的只是余额不一样。这样查询的话，每次需要关联3张表。如果真的这样实施，需要修改很多中间表的洗数流程。面对目前的数据量，我这种方案可行么？还有更好的修改方案么？ 怕自己盲目修改后，和之前的查询修改性能差不多，就白忙活了作者回复: 如果一亿的数据分12个月，那实际上每个月的表中大概是一千万左右的数据，这个量级的数据，在做好索引的前提下，查询不会很慢。 建议你先看一下查询的执行计划，找出为什么慢的原因。 另外，你没有提到表中的数据是否会频繁删除。如果频繁插入和删除数据的这张表，它的索引会越来越大，定期重建索引是有必要的。
2020-04-1967
