互联网大厂有哪些分库分表的思路和技巧？

互联网大厂有哪些分库分表的思路和技巧？

写在前面

冰河曾经经历过一个完整电商系统用户从零到上亿的研发过程，在业务的不断发展与变化过程中，演化出电商系统和基于大数据的商品精准实时推荐平台，关于 MySQL 数据库的架构演进，小伙伴们可以参考《从零到千万用户，我是如何一步步优化MySQL数据库的？》，关于系统的架构演进，小伙伴们可以参考《系统从初期到支撑亿级流量，都经历了哪些架构上的演变？》。在系统的研发过程中，随着数据量的不断增长，单库单表已无法满足数据的存储需求，此时，我们就需要对数据库进行分库分表操作。那在互联网大厂，分库分表通常有哪些思路和技巧呢？今天，我就将这些思路和技巧分享给大家。

注：本文已收录到：https://github.com/sunshinelyz/technology-binghe 和 https://gitee.com/binghe001/technology-binghe

分库分表

分库分表是随着业务的不断发展，单库单表无法承载整体的数据存储时，采取的一种将整体数据分散存储到不同服务器上的不同数据库中的不同数据表的存储方案。分库分表能够有效的缓解数据的存储压力，分库分表是数据存储达到一定规模时必然会遇到的问题。掌握分库分表的思路和技巧有助于小伙伴们更好的解决实际工作中，有关数据拆分的问题。

接下来，我们就分别对分表和分库来谈谈一些使用的思路和技巧。

分表

分表，最直白的意思，就是将一个表结构分为多个表，然后，可以再同一个库里，也可以放到不同的库。 当然，首先要知道什么情况下，才需要分表。个人觉得单表记录条数达到百万到千万级别时就要使用分表了。

分表的分类

1.纵向分表

将本来可以在同一个表的内容，人为划分为多个表。（所谓的本来，是指按照关系型数据库的第三范式要求，是应该在同一个表的。）

分表技巧： 根据数据的活跃度进行分离，（因为不同活跃的数据，处理方式是不同的）

案例：

对于一个博客系统，文章标题，作者，分类，创建时间等，是变化频率慢，查询次数多，而且最好有很好的实时性的数据，我们把它叫做冷数据。而博客的浏览量，回复数等，类似的统计信息，或者别的变化频率比较高的数据，我们把它叫做活跃数据。所以，在进行数据库结构设计的时候，就应该考虑分表，首先是纵向分表的处理。

这样纵向分表后：

（1）首先，存储引擎的使用不同，冷数据使用 MyIsam 可以有更好的查询数据。活跃数据，可以使用 Innodb ,可以有更好的更新速度。

（2）其次，对冷数据进行更多的从库配置，因为更多的操作时查询，这样来加快查询速度。对热数据，可以相对有更多的主库的横向分表处理。

其实，对于一些特殊的活跃数据，也可以考虑使用 memcache ,redis 之类的缓存，等累计到一定量再去更新数据库。或者 mongodb 一类的 nosql 数据库，这里只是举例，就先不说这个。

2.横向分表

字面意思，就可以看出来，是把大的表结构，横向切割为同样结构的不同表，如，用户信息表，user1,user2 等。表结构是完全一样，但是，根据某些特定的规则来划分的表，如根据用户 ID 来取模划分。

分表技巧： 根据数据量的规模来划分，保证单表的容量不会太大，从而来保证单表的查询等处理能力。

案例：

同上面的例子，博客系统。当博客的量达到很大的时候，就应该采取横向分割来降低每个单表的压力，来提升性能。例如博客的冷数据表，假如分为 100 个表，当同时有 100 万个用户在浏览时，如果是单表的话，会进行 100 万次请求，而现在分表后，就可能是每个表进行 1 万个数据的请求（因为，不可能绝对的平均，只是假设），这样压力就降低了很多。

注意：数据库的复制能解决访问问题，并不能解决大规模的并发写入问题，要解决这个问题就要考虑 MySQL 数据切分了。

数据切分

顾名思义，就是数据分散，将一台主机上的数据分摊到多台，减轻单台主机的负载压力，有两种切分方式，一种是分库，即按照业务模块分多个库，每个库中的表不一样，还有一种就是分表，按照一定的业务规则或者逻辑将数据拆分到不同的主机上，每个主机上的表是一样的，这个有点类似于 Oracle 的表分区。

分区

分库又叫垂直分区，这种方式实现起来比较简单，重要的是对业务要细化，分库时候要想清楚各个模块业务之间的交互情况，避免将来写程序时出现过多的跨库读写操作。

分表又叫水平分区，这种方式实现起来就比垂直分区复杂些，但是它能解决垂直分区所不能解决的问题，即单张表的访问及写入很频繁，这时候就可以根据一定的业务规则（PS：如互联网 BBS 论坛的会员等级概念，根据会员等级来分表）来分表，这样就能减轻单表压力，并且还能解决各个模块的之间的频繁交互问题。

分库的优点是： 实现简单，库与库之间界限分明，便于维护，缺点是不利于频繁跨库操作，不能解决单表数据量大的问题。

分表的优点是： 能解决分库的不足点，但是缺点却恰恰是分库的优点，分表实现起来比较复杂，特别是分表规则的划分，程序的编写，以及后期的数据库拆分移植维护。

实际应用

实际应用中，一般互联网企业的路线都是先分库再分表，两者结合使用，取长补短，这样发挥了 MySQL 扩展的最大优势，但是缺点是架构很大，很复杂，应用程序的编写也比较复杂。

以上是 MySQL 的数据切分的一些概念，数据切完了，现在要做的是怎么样在整合起来以便于外界访问，因为程序访问的入口永远只有一个，现在比较常用的解决方案是通过中间代理层来统一管控所有数据源。例如，可以使用冰河深度参与开发的 Mycat 中间件，也可以使用亮总开源的 ShardingSphere 中间件。

好了，今天就到这儿吧，我是冰河，我们下期见~~

写在最后

如果小伙伴们觉得我写的不错，可以加我微信，我拉你进技术交流群哦，这里有很多技术大牛每天分享自己的技术干货哦~~