关于分库分表

高并发，请求太多，扛不住了。(比如一台单机一般最好不要超过2000/s的QPS，高峰时期有8000QPS，这时候就要利用分库分表、消息中间件、数据库中间件、异步写来缓解服务器压力)
单机磁盘容量快满了
单表数据量太大，SQL越跑越慢

目前常用的有sharding-jdbc（基于client层)、mycat(基于proxy层)

client层优点在于不用部署，运维成本低，直接通过jar包导入所需的系统模块，缺点在于但是如果遇到升级的需求的话，各个系统模块都需要升级，耦合sharding-jdbc的依赖。

mycat缺点在于需要部署，自己运维一套中间件，运维成本高，但是好处在于对各个项目都是透明的，遇到升级直接在中间件升级就好了。

垂直拆分：把一个有很多字段的表拆分成多个表，或者是多个库上面去。每个库表，结构、字段都不一样。好处，举例：根据业务拆分，将常用的字段和不常用的字可以拆分成两张表，因为数据库是有缓存的，因此，访问频率高的行字段越少，缓存就可以存放更多行，性能就会更好。
水平拆分：根据表来进行分割：比如user表可以拆分为user0,、user1、user2、user3、user4等，实际应用中，通常可以先用hash法(比如取模)，也或者通过时间（周、月)来分到对应的库，在用hash法(比如取模)来分发到对应的表，这样可以提升性能。

大部分情况下，其实都是做的水平拆分，因为一般来说，垂直拆分在做表设计的时候就已经搞定了

另外一点，常用的有两种分库分表方式，一种是按range来划分，每个库都是一段连续的时间，比如一周、一月，这种方式一般比较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上。但是好处在于，扩容方便。

hash分发，好处在于，平均分配给库的数据量和请求压力，缺点在于扩容起来麻烦，会有数据迁移的一个过程。

通过前面说到的第三方中间件（sharding-jdbc（基于client层)、mycat(基于proxy层)）来实现，

原理：

客户端发送一条查询请求：select* from table;中间件会根据表有多少个子表，拆分成多个语句：select*from

tab1;selectfrom tab2;selectfrom tab3; 通过多条语句查询，然后将查询的结果返回给中间件，最后汇总给客户端，

这些查询语句是并行执行，所以效率会很高