-
一、背景
随着业务的不断扩展和业务量的快速增加，数据量就会越来越大，每次对表的操作都会占用更多的系统资源，若单表数据量过大，索引又多，这时候插入数据处
理速度就会变的很慢，这时候单机性能瓶颈就凸显出来了，那么如何解决呢？
映射到日常生活中，在一定条件下，把一件事分配给几个人一同处理的速度远大于一个人去处理的速度跟效率，这样即可以减轻每个人的压力，也可以提升整件事的
处理速度跟效率，但是要付出的人工成本就变高了，但是如果业务发展良好的话，从长远来看，收益将是投入成本的好多倍，其实是赚了。
所以可以考虑 两种方案:
1.部署上：采用 主从复制、读写分离。
2. 数据切分：将大数据表切分 散布到多个数据库主机上，达到均衡负载，突破单机性能瓶颈。
-
二、方案分析
第一种：主从复制 读写分离。这种是从部署方面来说的，但是随着业务量的不断增加和扩展，还是解决不了表数据量过大单机性能瓶颈的问题 插入、查询、位数索引文件过慢的问题。倘若遇见流量高峰期，或者并发期的时候，数据库有可能挂掉。所以这种方案也不能从根本上解决问题。但是这种部署方案几乎是大多数网站通用的部署的方式。可以考虑跟 方案2 和 方案3 相结合，做到优势互补。
第二种：
1. 垂直切分：可以根据一个业务涉及到的表之间的耦合度高低来切分，把一个业务中耦合度低的表，散布到多个数据库中，它们之间的耦合度低，相对于业务来说逻辑关联性也弱，没有那么多的join操作，较容易拆分，应用层的改动也较小，付出的成本也较低。例如把会员表和订单表放在不同的数据库中，但是这种方式缺点：
(1) 由于业务部分复杂度较高需要join操作，这就不好办了，只能通过应用程序或接口方式解决,如果部分业务需要事物方式处理，也是个头疼的问题，也不利于事务处理。
(2)当数据量达到一定规模还是会出现单库性能瓶颈
2.水平切分：把一个大表中的部分数据做切分 散布到多个数据库中，比如机构预约表，每天都会产生好几万条记录，可以根据机构的id取模运算，分散到不同数据表或者数据库中，水平切分可避免单表数据量过大影响查询和插入性能，减少占用系统资源，大流量或者并发场景下 数据库挂掉的可能行降低。
缺点：
(1)跨库join难度增加
(2)分布式事务处理复杂
总结：可以看出这两种切分方案：基本都存在 跨库join 问题、分布式事务处理繁杂问题。所以在设计表的时候一定要根据业务模型 找出最优切分方案。一般不是很大的系统中，可能只有部分业务数据量比较大，所以只有部分表需要做拆分，这个还比较好处理，但是大型系统就不能这么干了，不然付出的改造维护成本和时间成本会非常大。 现在有很多开源的数据库中间件，所以建议用数据库中间件来做处理，应用层只做应用层该做的事，不用考虑那么多，一些繁杂的数据处理交给中间件来做处理，这样开发效率也会大大提高。
