关于数据库的分库分表

什么是分库分表

从字面上简单理解，就是把本来存储于一个库的数据分块存储到多个库上，把本来存储于一个表的数据分块存储到多个表上。

为何分库分表

当一张表的数据达到几千万时，你查询一次所花的时间会变多，若是有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减少数据库的负担，缩短查询时间。

mysql中有一种机制是表锁定和行锁定，是为了保证数据的完整性。表锁定表示大家都不能对这张表进行操做，必须等我对表操做完才行。行锁定也同样，别的sql必须等我对这条数据操做完了，才能对这条数据进行操做。

如何分库分表

垂直切分

将表按照功能模块、关系密切程度划分出来，部署到不一样的库上。例如，咱们会创建定义数据库workDB、商品数据库payDB、用户数据库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。

水平切分

当一个表中的数据量过大时，咱们能够把该表的数据按照某种规则，例如userID散列，进行划分，而后存储到多个结构相同的表，和不一样的库上。例如，咱们的userDB中的用户数据表中，每个表的数据量都很大，就能够把userDB切分为结构相同的多个userDB：part0DB、part1DB等，再将userDB上的用户数据表userTable，切分为不少userTable：userTable0、userTable1等，而后将这些表按照必定的规则存储到多个userDB上。

切分的选择

应该使用哪种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。

若是数据库是由于表太多而形成海量数据，而且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。而若是数据库中的表并很少，但单表的数据量很大、或数据热度很高，这种状况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将本来逻辑上属于一体的数据进行了物理分割，除了在分割时要对分割的粒度作好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。

在现实项目中，每每是这两种状况兼而有之，这就须要作出权衡，甚至既须要垂直切分，又须要水平切分。咱们的游戏项目便综合使用了垂直与水平切分，咱们首先对数据库进行垂直切分，而后，再针对一部分表，一般是用户数据表，进行水平切分。

Mysql中的分库分表

好比对于某网站平台的数据库表-公司表，数据量很大，这种能预估出来的大数据量表，咱们就事先分出个N个表，这个N是多少，根据实际状况而定。某网站如今的数据量至可能是5000万条，能够设计每张表容纳的数据量是500万条，也就是拆分红10张表，那么如何判断某张表的数据是否容量已满呢？能够在程序段对于要新增数据的表，在插入前先作统计表记录数量的操做，当<500万条数据，就直接插入，当已经到达阀值，能够在程序段新建立数据库表（或者已经事先建立好），再执行插入操做。

利用merge存储引擎来实现分表

若是要把已有的大数据量表分开比较痛苦，最痛苦的事就是改代码，由于程序里面的sql语句已经写好了。用merge存储引擎来实现分表, 这种方法比较适合.

分库分表存在的问题

事务问题

在执行分库分表以后，因为数据存储到了不一样的库上，数据库事务管理出现了困难。若是依赖数据库自己的分布式事务管理功能去执行事务，将付出高昂的性能代价；若是由应用程序去协助控制，造成程序逻辑上的事务，又会形成编程方面的负担。

跨库跨表的join问题

在执行了分库分表以后，难以免会将本来逻辑关联性很强的数据划分到不一样的表、不一样的库上，这时，表的关联操做将受到限制，咱们没法join位于不一样分库的表，也没法join分表粒度不一样的表，结果本来一次查询可以完成的业务，可能须要屡次查询才能完成。

额外的数据管理负担和数据运算压力

额外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些均可以经过应用程序解决，但必然引发额外的逻辑运算，例如，对于一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表以前，只需一个order by语句就能够搞定，可是在进行分表以后，将须要n个order by语句，分别查出每个分表的前100名用户数据，而后再对这些数据进行合并计算，才能得出结果。

简单的MySQL主从复制

MySQL的主从复制解决了数据库的读写分离，并很好的提高了读的性能，其图以下：

其主从复制的过程以下图所示：

可是，主从复制也带来其余一系列性能瓶颈问题：

• 写入没法扩展
• 写入没法缓存
• 复制延时
• 锁表率上升
• 表变大，缓存率降低

那问题产生总得解决的，这就产生下面的优化方案，一块儿来看看。

MySQL垂直分区

若是把业务切割得足够独立，那把不一样业务的数据放到不一样的数据库服务器将是一个不错的方案，并且万一其中一个业务崩溃了也不会影响其余业务的正常进行，而且也起到了负载分流的做用，大大提高了数据库的吞吐能力。通过垂直分区后的数据库架构图以下：

然而，尽管业务之间已经足够独立了，可是有些业务之间或多或少总会有点联系，如用户，基本上都会和每一个业务相关联，何况这种分区方式，也不能解决单张表数据量暴涨的问题，所以为什么不试试水平分割呢？

MySQL水平分片（Sharding）

这是一个很是好的思路，将用户按必定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增长，只要简单地配置一台服务器便可，原理图以下：

如何来肯定某个用户所在的shard呢，能够建一张用户和shard对应的数据表，每次请求先从这张表找用户的shard id，再从对应shard中查询相关数据，以下图所示：