网上所谓的大厂分库分表，都是错的！

点击卡片，关注 InsideMySQL

问各位小可爱一个问题：什么是分库分表？

这是个有意思的问题，因为姜老师发现分库分表是中国特色数据库才有的定义，你在英文文献中找不到对应英文单词。

一言以蔽之，分库分表就是是将数据分片（Sharding），从而提升数据库的容量。

注意，这里的容量是指存储容量和性能容量。

第二个问题，为什么要进行分库分表呢？

我们来看下知乎上，华为云开发者社区的回答。

可以看到，华为云开发者社区认为 MySQL 数据库单表的上限是1000万内。

若超过，则从性能考量，需要进行拆分处理。

然而，以上全错。

MySQL 单表的存储上限是64T。另一方面，单表 1000W 和 5000W的性能几乎一样，没有太大区别。

这是个非常有意思的话题，所以姜老师就在 IMG 微信群发起了投票，看看 IMG 小可爱们的投票结果：

不好意思，投票的不是她们。投票结果应该是：

IMG 群的小可爱对于大数据的定义就高多了，认为超过1亿才需要进行分库分表的同学占比达到了63.2%。

认为超过1000万就需要进行分库分表的同学占比32.3%。

然而，竟然有4.6%的同学会认为超过100万就需要进行分库分表！

请问你们是负责的是 PostgreSQL ，又或是 TiDB 数据库么？

即便上述所有选项，答案依然是：以上全错。

但凡用单表记录数去评估是否需要进行分库分表，都是错的。

1000W的表，和100亿的表，访问单条数据的性能是差不多的。因为都是B+树索引的数据结构。

B+树索引高度为3和5，也就0.0003和0.0005秒，看似慢了近1倍的时间，但从业务角度看并没太大影响。

衡量是否需要进行分库分表的标准有且仅有：容量。

这里的容量是指存储容量，性能容量。

容量不是瓶颈非要去做分库分表设计，那就是脱裤子放屁，多此一举。

当然，这里只谈技术环节，不谈商业逻辑。

因为如果你能像理想汽车那样，用三流的技术，二流的用户体验，卖出一流的价格，那是一种非凡的本事。

so，姜老师不屑的一直是 TiDB 这样架构的数据库，对 TiDB 公司我无比尊敬。

网上所谓的大厂分库分表，大多都是错的，包括大厂本身。

大厂即便是错，那最多也就是过度设计。

大厂有一堆分库分表的配套组件，用起来已经相对顺手。

再次强调，分库分表的第一性原理是：容量，存储容量和性能容量。

没有容量规划，谈分库分表都是空谈。

让每天增量1万条记录的业务表做分库分表设计，那就是扯蛋；

让每天高峰 QPS 1000 的业务去做分库分表设计，那就是蛋疼；

天天跟你谈分库分表，分布式架构有多香的人，赶紧让他滚蛋。

核心业务系统才需要精心设计的分库分表方案。

即通过分布式架构解决传统单一 Oracle 数据库的瓶颈。

写到这，姜老师已经 call back 好多次关于分库分表的前提：容量，存储容量和性能容量。

存储容量比较好理解，那就是单一数据库实例的存储是不是瓶颈？

举个例子，监控系统每10秒收集一批监控数据，数据大小为8K。假设你的监控系统负责下面1000台服务器的上报，那么每天的存储开销为（这里不考虑压缩问题）：

（6*10*8K） * 24 * 60 * 1000 ≈ 70G

若磁盘大小为2T，那么监控数据库仅能存放约30天时间。

若要存放超过30天的数据呢？

最简单的是仅保留30天的数据，30天前的数据删除。

但是如何快速删除30天前的数据呢？

用 DELETE 操作是很慢的。

所以，可以按天分表，线上保留30天的表。

然而，若业务发展，监控的服务器数量从1000台变成了1500台呢？保留到15天？

这时，可以考虑分库，分成100个库，每个库保留30天的数据。分库的规则可以根据监控服务器ID进行哈希。

然后把这100个库放到1个、10个、还是100个数据库实例，那可以根据容量来进行具体规划。

如果是前面的例子，1000台到1500台，那么根据分库分表的设计，可以每个数据库实例存放50个库，每个库都保留30天的数据。

上面的这个分库分表设计是一个拥有两层的数据分片策略。第一层根据每个服务器ID分片数据，第二层是根据日期再进行数据的分片。

第一层分片可以很好解决存储容量的瓶颈问题，第二层分片用于方便解决日后的数据清理工作。

当然，分库分表设计最重要的是解决性能容量问题，这才是核心业务系统最为关心的内容。

我们来进行性能的容量规划~~~

下图是天猫公布的双11订单数据：

不好意思，手抖了，应该是：

对于数据库来说，对应的峰值 TPS 应该就是58.3W

若单台数据库服务器的性能上限是 3000 TPS，则需约200台服务器才能满足业务的需求，而这还仅仅是天猫的量。

可以看到，单实例数据库就是会存在性能瓶颈，即便用 Oracle 数据库也解决不了问题。

因此，这时需要引入分库分表的分布式架构设计，通过水平扩容（Scale Out）的方式解决性能容量问题。

这也是分库分表最有意义的场景。

然而，试问又有多少企业真正存在如此的性能容量瓶颈呢？

思考题

其实通过分库分表设计去解决存储容量瓶颈并不是最优的设计，而且会引入很多额外的问题。

例如需要对数据进行汇总查询，又或比较2台服务器监控数据的差异等。

这是因为分片后数据有很大概率分布在不同服务器的不同表中。

那么对于存储容量是瓶颈的表结构设计，除了分库分表，最优的设计应该是什么呢？

欢迎加入 IMG 官方社区高端群，这里会有思考题的标准答案哦！

IMG仅限码农入群，猎头或其他行业勿加。

入群请加姜老师个人微信 82946772，并备注：码农入群

本公众号最早于2015年创立，已经陪各位同学走过了7年的时间，总计有4个微信群：少林、武当、峨眉、华山。

其中不少同学姜老师都是看着从初出茅庐的技术小白跳槽到大厂、然后开启逆袭的人生，买房、结婚、生娃、买二套房、跳槽、移民......

很荣幸，也很开心，姜老师是真心希望能带着每个 IMG 群的码农起飞，过上理想中的生活。

7年时间，变化真的很大，数据库也已经进入到 NewSQL 时代。

现在呢，希望各位同学能跟随姜老师进入到 NewDev、NewDBA、NewOps的时代，也就是我们的 IMG 官方社区高端群。

IMG 官方社区高端群是年费制的，不过也就99元/年，权当请姜老师喝杯咖啡。

但在会员期间你可以享受到下面的福利：

• 突破微信群人数500的限制，以后所有高端群小伙伴可以在一起吹水；
  

• 提供 IMG 公众号每篇技术文章最后遗留问题的标准答案；

• 技术圈的江湖八卦，比如某数据库出局某行的原委，某大V被新领导GZ；

• IMG社区技术嘉年华大会门票5折优惠；

• 姜老师夫妇的私密分享，包括技术、工作、投资、相亲、移民等热门话题；
  

• 会员每邀请新会员入群，可以享受59元的返利（把年费赚回来😄）；

往期推荐