分库分表
我们经常把分库分表放在一起说，理论上其实分库和分表达到的效果是相同的，分库分表是为了减轻数据库压力，提高效率。
现代业务越来越复杂，数据量也越来越大，关系型数据库本身就比较容易形成系统瓶颈，单机存储容量，连接数，处理能力都有限。同理单库，单表的处理能力更加有限，所以分库分表中心思想都是将数据分散，使得单一数据库/表的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的。
垂直分表/分库
垂直分表定义：将一个表按照字段分为多表，每个表里面都存储其中一部分字段。
垂直分库定义：专库专用，按照业务将表进行分类，分布在不同的数据库中，每个库可以放在不同的服务器上
从描述上直接理解，其实就是把一张表，从上往下切开，把不同的字段分布到不同的表里，因为从业务上，可以区分热点字段和非热点字段，可以依照这个来分。
意义
解决了热点数据的效率问题，分页等操作方便，但是对于大数据量无效。
水平分表分库
水平分表定义：同一个数据库内，对数据行拆分，不影响表结构。
水平分库定义：同一个表的数据按一定规则拆到不同的数据库中，库放在不同的服务器上。
从描述上直接理解，就是把一张表，从左到右切开，分完之后的表字段仍旧相同，但是数据内容是不同的，所有这些水平分表之后的表数据加在一起，才是完整的一份数据。
意义
解决了单库/单表的存储量和性能问题，但是对于一些查询操作增加了难度，对分页也有影响。
实例
假设这样一种情况，有一个订单表，目前有1亿数据，日增量为500万，我们的常用查询为，根据订单id查某条数据，或者根据用户id查用户的订单数据，我们应该如何进行分库分表操作呢?
分析
单表500w - 800w 数据，2G数据； 单库100G， 1w QPS , 5k TPS
这里我们假设该表有10个字段，每个字段100字节，一条数据共1000个字节。
1KB x 1亿约为100G左右。
假设我们本次进行分库分表，想要解决3年内的数据增长，也就是
365天 x 3年 x 500万 x 1KB 数据，约为5221G数据，55亿条左右。
首先我们先明确几个数据，目前我们常用的数据库服务器，按照8G内存来算，每个表大概存800万数据。55亿/800万约为688张表，按照700张表来算。
那么每个库里多少张表呢？这个涉及到qps，可以根据qps来计算一下。这里就不举例了。
计算方法大概就是上面这样
方案
也就是说，我们要进行水平分库分表，有两种方案，一种是按照用户hash，某个用户的所有订单数据都存到一个表里，另一种是按照订单id来hash，这样便于直接通过订单id来查询数据。
第一种
按照用户id来hash进行分表，当我们想要查询某个用户的所有订单，是很方便定位的，但是此时如果我们想通过某个订单id来查，会发现无从查起，所以我们需要另一张用户和订单的关联表（这个表也可以是分库分表的）来进行订单id的辅助查询。
第二种
按照订单id来hash进行分表，当我们使用某个订单id来查询时，很方便定位，但是查用户的订单会很麻烦，从我们表的数量来说，所有表都查一遍不太现实，所以也需要另一张用户和订单的关联表（这个表也可以是分库分表的）来进行用户订单的辅助查询。
其他
另外，需要注意的是，随着时间的流逝，我们可能没有必要把所有数据都存到mysql里，毕竟它不是分析型的数据库，我们可以根据时间，把老的数据放到一些其他适合查询场景的库里，比如淘宝使用的是X-Engine引擎的PolarDB-X集群（虽然我也没研究这是个啥呢）。
以上
不过实际上我也没见过这么多数据，我好没经验，有经验的大佬希望可以评论里分享下实际业务里都咋分，谢谢。
