前言
现在的互联网公司基本都是分布式，多服务了，所以这给分库分表提供了更好的空间。而且随着数据量的增大，单库单表难免满足不了性能要求。
单库单表会涉及到以下几个问题：
1.单库表太多；单个数据库处理能力有限；单库所在服务器上磁盘空间不足；单库上操作的IO瓶颈
解决方法：根据业务拆分成更多更小的库
2.单表数据量大；CRUD都成问题；索引膨胀，查询超时
解决方法：将单表拆分成数据集更少的表
案例：不使用分库分表例子
曾经看过这么个案例博文：将数据库的写操作和读操作分离，主库(Master)负责写，多个从库(Slaver)负责读，从库从主库同步更新数据，保持数据同步，从库可以水平扩展，可应付更多请求。
但是当用户数据达到一定数量级别后，写操作越来越频繁，加一个Master是不能解决问题的， 因为数据要保存一致性，写操作需要2个master之间同步，相当于是重复了，而且更加复杂，于是主从同步不适应了，需要使用分库分表。
分库分表的方式方法：
垂直方式和水平方式
如果是因为表多而导致数据多，可以采用垂直方式，根据业务切分成不同的库；
如果是因为单表数据量太大，就可以采用水平方式，即把表的数据按某种规则切分成多张表，甚至多个库上的多张表。
分库分表的顺序应该是先垂直分，后水平分。 因为垂直分更简单，更符合我们处理现实世界问题的方式。
1.垂直分表： 大表拆小表，基于字段进行，将不常用、数据量大的字段拆分到“扩展表“，也可避免数据量查询时造成的“跨页”问题。
2.垂直分库： 按业务进行划分库，比如用户服务相关数据划分在用户库，商品服务相关数据划分到商品库等
3.水平分表： 对数据量巨大的表，可按照某种规则(如range,time,hash)切分到多张表里面去。但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。不建议采用。
4.水平分库分表： 将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表可解决单机单库性能瓶颈和压力，突破IO、连接数等问题。
水平分库分表规则：
4.1 range: 比如id在0-10000一个表，10000-2000一个表等
4.2 hash: 根据hash取模id，分配到不同的数据库上
4.3 地理区域: 根据数据产生的地理位置划分，比如华南地区、华北地区等
4.3 根据时间：比如一个月分一张表
分库分表方案产品
1.sharding-jdbc: 该产品是当当开源的实现透明化数据库分库分表框架。
2.mysql-proxy：mysql官方提供的中间件产品可以实现负载平衡，读写分离，failover等。
3.还有mycat、Atlas等
