分库分表的种类：
这里说的分库分表是把数据库中的数据物理地拆分到多个实例或者多台服务器上，而不是MySQL原生的Partitioining。
MySQL官方的Partitioning可以将一张表的数据库分别存储为多个文件，如果在写SQL的时候遵从了分区规则，就能把原本需要遍历全表的工作转化为只需要遍历表里一个或者部分分区的工作，这样就降低了查询对服务器的压力。但是这样不管怎么分区，所有数据都在一个服务器上边，没有办法通过水平扩展物理服务的方法把压力分摊出去。
垂直拆分：
考虑数据库拆分的时候，首先考虑垂直拆分，其次考虑水平拆分。垂直拆分可以理解为分出来的库表结构是互相独立各不相同的。
1）如果有多个业务，业务之间的关联性不大，就可以把不同业务拆分为单独的实例，库或表。
2）如果在一个实例上边，有多个数据库，可以把每个数据库拆分到单独的实例上。
3）如果一个库中有多张表，可以把每张表拆分到不同的实例上。
4）如果有一张表，但表里字段太多，当表太大的时候，可以把每个或者几个字段拆分为一个表。
水平拆分：
水平拆分是针对一张表说的，在经过垂直拆分之后，如果表的数据库依然过大，例如注册用户量超过10亿，那只好通过某种算法进行水平拆分。拆分之后结果是多张具有相同表结构的表，每张表里存储一部分数据。拆分的方法依据很多，例如通过取模100、2014等。
分库分表的原则：
原则零：能不分就不分
如果能对系统进行升级来提升数据库的性能，例如升级硬盘、cpu、内存、网络、数据库版本、读写分离、负载均衡等方面解决问题，就不要做分表分库。也就是说做分表分库的前提是这些已经做好了。
原则一：数据量太大，正常的运维影响正常的业务访问。
1）对数据库的备份，如单个表太大，做数据库备份的时候需要大量的磁盘IO或者网络IO资源。
2）对数据表的修改，如表数据库太大，做DDL时候会对表加锁，这个时间会很长。
3）整个表的热点数据，如某表的user_last_login字段，频繁进行update操作，导致此表压力过大。
原则二：表设计不合理，对某些字段垂直拆分
1）用户数从100万飙升到10亿，user_last_login字段不断被update，最好的办法就是把该字段垂直拆分出去。
2）用户表的person_info 表本来没什么用，但是有些用户会把个人信息填写的分成完善，更糟糕的是产品经理心血来潮，要把该字段开放，其他所有人都可以访问，而该字段的类型是text，这个必须要进行拆分。
原则三：某些数据出现了无穷尽的增长
比如聊天系统的聊天记录，充值系统的充值记录等等。
原则四：安全性和可用性的考虑
不要把所有鸡蛋都放在一个篮子里，我们不希望数据库出问题，或者不希望100%的用户受到影响。如把用户、库存、订单等本来统一的资源进行拆分。
原则五：业务耦合性考虑
火车票业务和烤羊腿业务不沾边，完全可以拆分为不同的数据库。