分库分表

分库分表的方法一般就是垂直和水平拆分。

分库：针对请求量大，而不是数据量大。将大量请求拆分到不同的机器上，才能降低业务的压力。所以一般也是根据业务类型进行拆分。订单，用户，商品，日志，统计等进行拆分。

分表：是针对数据量大。一般来说业内500w或者2Gb，就需要进行拆分了。
这里补充一点，mysql单表的性能瓶颈是由机器决定的

1. 垂直分表将表中字段拆分，依据是业务，前提你要对自己的系统业务很熟悉才行。比如用户表，常用的字段放在一个表，扩展信息不常用的放在另一个表。

2. 水平拆分表可以根据表中字段的范围、取模、时间等。

整体的思路：
实在不能够优化了，单机的瓶颈达到了限制，那么最快最直接的就是升级机器。
接下去不行，那么开始考虑是分库还是分表。尽可能的改动小。
分库没有涉及因为机器性能够了，业务没有那么大。

看具体的业务，如果是请求数很多，那么是分库。这个时候分表效益不高，因为请求都是在一台服务器上，这个数据库的压力还是没有减少。（严格来说也不是说请求量大就是分库，首先是前端需要做负载，如果前端压力降下来了，数据库这边因为连接数等问题还是压力很大，就要考虑分库，看mysql的负载等其他直接反应负载高的参数）。
如何分库：根据数据在不同的库上，比如查询用户数据，是根据用户id进行查询的，那么根据用户id，hash取模出来的就在某一个库上，这样不同的用户就会分配到不同的数据库上进行操作。
可见这种操作是影响到了很多东西的。代码要经过大的改动，数据库的连接逻辑变了，所有涉及到操作用户的地方逻辑都变了，以下为总结的可能涉及到的问题 ↓

导致的问题

1、跨库join问题。比如查询用户相关的商品信息，不同的用户在不同的库上，那么如果是join查询就会失败。当然可以通过业务来避免，总之就是要处理好每个关系。
2、数据维度问题。商家的商品数据如果是根据商家的维度进行分库，那么用户查询某个分类商品的时候就会出现问题，这个情况就会出现跨库操作。
3、事务一致性问题。这个不用说了，不同的库，肯定会有这种问题。
4、分页排序难度增加。这些都涉及到垮库操作。

总结

所有出现的问题都是因为一个问题——跨库操作。因为业务逻辑是多个维度的。很多时候不可避免要进行垮库操作。
是否有好的解决方案呢？？
网上找的：多维度存储。用到什么存什么（感觉是空间换时间）。

误区：分库是不同的数据在不同的库上，但是每个库中每个表的类型是一致的。

如果是因为请求表的数据量多导致慢，卡顿，考虑分表，将数据量进行拆分，比如很多日志统计类的数据，按照时间，月份星期，具体的看数据量，比如100w条数据一个表，如果一天就有那么多，就按照天来，然后定期备份，清理表。虽然理论上单库支持的表为20亿张表，对，是20亿~ 。
当然这个数据量还是和机器性能有关系，如果你机器性能io，cpu都能够支持mysql，那么不分库也没事。

代码实现思路

首先取表中某个字段进行计算——hash、取模、等其他方法，根据路由算法表绑定到具体的库或者表上。

参考链接：
https://blog.csdn.net/nuli888/article/details/52143065