每个优秀的程序员和架构师都应该掌握分库分表，这是我的观点。
移动互联网时代，海量的用户每天产生海量的数量，比如：
-
用户表
-
订单表
-
交易流水表
以支付宝用户为例，8亿；微信用户更是10亿。订单表更夸张，比如美团外卖，每天都是几千万的订单。淘宝的历史订单总量应该百亿，甚至千亿级别，这些海量数据远不是一张表能Hold住的。事实上MySQL单表可以存储10亿级数据，只是这时候性能比较差，业界公认MySQL单表容量在1KW以下是最佳状态，因为这时它的BTREE索引树高在3~5之间。
既然一张表无法搞定，那么就想办法将数据放到多个地方，目前比较普遍的方案有3个：
-
分区；
-
分库分表；
-
NoSQL/NewSQL；
说明：只分库，或者只分表，或者分库分表融合方案都统一认为是分库分表方案，因为分库，或者分表只是一种特殊的分库分表而已。NoSQL比较具有代表性的是MongoDB，es。NewSQL比较具有代表性的是TiDB。
Why Not NoSQL/NewSQL?
首先，为什么不选择第三种方案NoSQL/NewSQL，我认为主要是RDBMS有以下几个优点：
- RDBMS生态完善；
- RDBMS绝对稳定；
- RDBMS的事务特性；
NoSQL/NewSQL作为新生儿，在我们把可靠性当做首要考察对象时，它是无法与RDBMS相提并论的。RDBMS发展几十年，只要有软件的地方，它都是核心存储的首选。
目前绝大部分公司的核心数据都是：以RDBMS存储为主，NoSQL/NewSQL存储为辅！互联网公司又以MySQL为主，国企&银行等不差钱的企业以Oracle/DB2为主！NoSQL/NewSQL宣传的无论多牛逼，就现在各大公司对它的定位，都是RDBMS的补充，而不是取而代之！
Why Not 分区?
我们再看分区表方案。了解这个方案之前，先了解它的原理：
分区表是由多个相关的底层表实现，这些底层表也是由句柄对象表示，所以我们也可以直接访问各个分区，存储引擎管理分区的各个底层表和管理普通表一样（所有的底层表都必须使用相同的存储引擎），分区表的索引只是在各个底层表上各自加上一个相同的索引，从存储引擎的角度来看，底层表和一个普通表没有任何不同，存储引擎也无须知道这是一个普通表还是一个分区表的一部分。
事实上，这个方案也不错，它对用户屏蔽了sharding的细节，即使查询条件没有sharding column，它也能正常工作（只是这时候性能一般）。不过它的缺点很明显：很多的资源都受到单机的限制，例如连接数，网络吞吐等！虽然每个分区可以独立存储，但是分区表的总入口还是一个MySQL示例。从而导致它的并发能力非常一般，远远达不到互联网高并发的要求！
至于网上提到的一些其他缺点比如：无法使用外键，不支持全文索引。我认为这都不算缺点，21世纪的项目如果还是使用外键和数据库的全文索引，我都懒得吐槽了！
所以，如果使用分区表，你的业务应该具备如下两个特点：
-
数据不是海量（分区数有限，存储能力就有限）；
-
并发能力要求不高；
Why 分库分表?
最后要介绍的就是目前互联网行业处理海量数据的通用方法：分库分表。
虽然大家都是采用分库分表方案来处理海量核心数据，但是还没有一个一统江湖的中间件，笔者这里列举一些有一定知名度的分库分表中间件：
-
阿里的TDDL，DRDS和cobar，
-
开源社区的sharding-jdbc（3.x已经更名为sharding-sphere）；
-
民间组织的MyCAT；
-
360的Atlas；
-
美团的zebra；
其他比如网易，58，京东等公司都有自研的中间件。总之各自为战，也可以说是百花齐放。
但是这么多的分库分表中间件全部可以归结为两大类型：
-
CLIENT模式；
-
PROXY模式；
CLIENT模式代表有阿里的TDDL，开源社区的sharding-jdbc（sharding-jdbc的3.x版本即sharding-sphere已经支持了proxy模式）。架构如下：
PROXY模式代表有阿里的cobar，民间组织的MyCAT。架构如下：
但是，无论是CLIENT模式，还是PROXY模式。几个核心的步骤是一样的：SQL解析，重写，路由，执行，结果归并。