为什么要分库分表（个人理解，希望能与大家共勉）

• 前言

 其实分库分表是牵扯到高并发的，因为分库分表无非来说就是为了支撑高并发、数据量大的问题。尤其进入稍微大一点的公司或者互联网公司，这些都是必须掌握！

• 场景

 假如一个新兴公司，刚开始时，注册用户就40W，每天活跃1W，每天单表数据量1000，高峰期每秒的并发就10，这种一般的单表单库操作就可以搞定。

但是，当用户不断增加、日活跃用户增加、单表数据量增加、高峰期每秒增加到一定数量时，单表单库性能就存在很大的问题了。

• 解决办法-->分表

前提：当单表数据量太大，会极大的影响sql的执行性能，这时sql会跑的很慢。根据实战经验来说，当单表到几百万的时候，性能就会有所下降

个人理解：白话来说就是把一个表的数据放到多个表中，查就查一个表，可以按照id来分表控制每个表的数据量，比如单表固定在200W以内。

• 解决办法-->分库

个人理解：单库而言，最大的并发可能就2000左右，但是一个健壮的单库来说最好的并发保持在1000左右。单数据库增大或者并发增加的时候，可以将一个库的数据拆分到多个库中。 

• 分库分表图表理解

	分库分表前	分库分表后
并发情况	Mysql单机，支撑不了高并发	Mysql集群，并发加倍
磁盘情况	磁盘容量几乎撑满	拆分多个表，磁盘使用率降低
SQL性能	数据量加大，SQL越来越慢	单表数据量少，SQL效率提升明显

• 目前常用的分库分表中间件

 sharding-jdbc：当当开源，属于client层，SQL语法支持比较多，支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务），一直在维护，社区也比较活跃

mycat：基于proxy层方案，属于目前非常火且不断更新的数据库中间件，支持功能也非常完善

 区别和选择：

sharding-jdbc这种client层优点是不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是一旦升级，需要各个系统都重新升级版本在发布，各个系统都需要耦合sharding-jdbc的依赖。

mycat这种proxy层的方案缺点就是自己运维一套中间件，运维成本高，但是好处在于对于各个项目透明，如果升级都是在中间件那里搞定就可以了。

通常来说，小公司小项目建议使用sharding-jdbc，维护成本低，而大公司使用mycat这种proxy方案，大公司系统和项目多，有专人维护。

 

 就是把一个表的数据分到多个库的多个表中，每个库的表结构一样，不过每个库存放的数据不同。水平拆分的意思就是将数据均匀放到更多表里，然后多个库来抗高并发，还有就是用多个库的存储容量来扩容

• 数据库水平拆分

 

• 数据库垂直拆分

 就是把一个很多字段的表拆分给多个表，或者多个库上去。每个库表结构都不一样，每个库表都包含部分字段。一般来说，会将很少访问的字段放到一个表，数据库有缓存，访问频率高的字段越少，可以缓存更多的行，性能更好，这个一般在表层面操作。

• 如何来拆分

其实大家可能都遇到到，比如说把一个订单大表拆开，订单表、订单支付表、订单商品表。

一种是按照range来分，每个库一段连续的数据，比如按时间来，但比较少用，比如大量流量产生大量数据。

一种是按照某个字段hash均匀分散，这个较常用