mysql分库分表的原则

分库分表的种类

分库分表是指把数据库中数据物理地拆分到多个实例或多台机器上，非mysql原生态partitioning。

partitioning是mysql官方支持，在本地针对表的分区进行操作，它 可以将一张表的数据分别存储为多个文件。如果在写SQL的时候，遵从了分区的规则，就能把原本需要遍历全表的工作转变为只需要遍历表里某一个分区或某些分区的工作，这样降低了查询对服务器的压力，提升了查询效率，如果分区表使用得当，也可以大规模地提升mysql的服务能力。

但是这种分区方式，一方面，在使用的时候必须遵从分区规则写SQL语句，如果不符合分区规则，性能反而非常低下，另一方面，partitioning的结果受到但实力的数据文件无法分布式存储的限制，不管怎么分区，所有的数据都是在一个服务器上，没办法通过水平扩展物理服务器的方法吧压力分摊出去。

1，垂直拆分

在考虑数据库拆分的时候，一般情况下，应该先考虑垂直拆分，垂直可以理解为分出来的库表结构是互相独立各不相同的。

-如果有多个业务，每个业务直接关联性不大，那么久可以把每个业务拆分为单独的实例，库或表。

-如果在一个实例上，有多个数据库，那么从分摊压力的角度考虑，可以把每个数据库才分到单独的实例上。

-如果在一个库里面有多张表，那么可以把每张表拆分到不同的实例上。

-如果你有一张表，但这个表里的字段很多，每个字段都有不同的含义，如t1表里面有姓名生日，地址等个人信息，那么当该表太大的时候，就可以把每个字段独立拆分为一张新表。

2，水平拆分

水平拆分是真对一张表来说的。在经过垂直拆分之后，如果数据量仍然巨大，如注册用户已经超过10亿，那么治好通过某种算法进行水平拆分。拆分后的结果是多张具有相同表结构的表，每张表里面存储一部分数据，拆分的算分依据很多，如通过id取模100,1024的方式以及通过区分不同日期的方式。

分库分表的原则

1，能不分就不分

mysql是关系型数据库，数据库表之间的关系从一定的角度上映射了业务逻辑，任何分库分表的行为都会在某种程度上提升业务逻辑的复杂度，数据库除了承载数据的存储和访问外，协助业务更好地实现需求和逻辑也是其重要工作之一。分库分表会带来数据的合并，查询或更新条件的分离，以及事务的分离等多种结果，业务实现的复杂程度往往会翻倍或指数级上升。所以，在分库分表前，不要为分而分，而应该尽量去做其他力所能及的事情，例如升级硬盘，升级内存，升级CPU，升级网络，升级数据库版本，读写分离及负载均衡等，所有分库分表的前提是，这些已经尽力做好了。

2，数据量太大，正常的运维影响正常的业务访问

这里说的运维包括乳腺三种情况

-对数据库的备份。如果单表或单个实例太大，在做备份的时候需要大量的磁盘IO或网络IO资源，备份整个过程中维护风险是高于平时的，一个解决方案是为每台设备额外添加第二张网卡。

-对数据表的修改。如果某张表过大，对此表做DDL的时候，mysql会锁住全表，这个时间可能会很长，在这段时间内业务不能访问此表，影响甚大，把数据表切分，使总量减小，有助于改善这种风险。

-整个表的热点数据，数据访问和更新频繁，经常有锁等待，没有能力修改源码，降低锁的粒度，那么只会把其中数据物理的拆开，用空间换时间，变相降低了访问压力。

3，某些数据表出现了无穷增长的情况

各种评论，消息，日志记录，这个增长不是跟人口成比例的，是不可控的。

4，安全性和可用性的考虑

把用户，库存，订单等本来同一的资源切分掉，每个小的数据库实例承担一小部分业务，这样整体的可用性就会提升。

5，业务耦合性考虑

站在业务的层面看，火车票业务和烤猪腿业务是完全不相关的业务，虽然每个业务的数据量可能都不太大，放在一个实例中完全没问题，但是不同业务的维护水平可能不同，火车票业务经常会受到烤猪腿业务的牵连，这个你懂的。惹不起，躲得起。

6，分库分表实现

分库分表的实现，主要体现在两个方面。一方面是把数据库原来数据的存储位置前移到新的库表里；另一方面，数据库的拆分实际上破坏了数据库的关系逻辑，原本的SQL访问可能不在使用，在业务成，怎样才能最好的继续使用数据库，也是个难点。

7，业务层的实现

在业务层面，怎么去读写经过拆分之后分布式存储的数据

-通过在业务程序端嵌入客户端软件包的形式，在业务需要访问数据库的时候，首先访问路由表，在由路由表判断需要访问mysql数据库的位置，然后业务端直接练就数据库，做直接的数据库操作，，如果需要进行数据的合并，则在业务程序端实现，或者在嵌入的客户端软件包里面实现。

-通过proxy的形式。