关于分库分表的思路

看到一篇分库、分表的文章写的通俗易懂。转载过来分享给大家

原文连接
支持原文作者，请点击原文链接查看

上结论

分库分表主要分为 垂直方向 和 水平方向，垂直方向倾向于业务拆分，水平方向倾向于数据拆分。垂直方向（即业务方向）实现更简单，在水平方向（即数据方向）上，分库和分表的作用是有区别的，不能混为一谈

分库 是为了解决数据库连接资源不足和磁盘IO的性能瓶颈问题。
分表 是为了解决单表数据量太大时，即使走了索引查询也非常耗时问题，此外还可以解决消耗cpu资源问题。
分库分表 可以解决 数据库连接资源不足、磁盘IO的性能瓶颈、检索数据耗时 和 消耗cpu资源等问题。

1. 如果在有些业务场景中，用户并发量很大，但是需要保存的数据量很少，这时可以只分库，不分表。

2. 如果在有些业务场景中，用户并发量不大，但是需要保存的数量很多，这时可以只分表，不分库。

3. 如果在有些业务场景中，用户并发量大，并且需要保存的数量也很多时，可以分库分表。

1. 垂直方向

1.1 垂直拆分表

背景：
经过业务的不断丰富和扩张，表字段可能会增加膨胀到几十个甚至上百个。这时维护表会变得越来越困难，并且一般表中只有部分字段为热点字段。
处理：
以用户表为例，将用户表拆分为基本信息表、扩展信息表

通过分表把核心数据和非核心数据分开，让表的结构更清晰，职责更单一，更便于维护。
除了按实际业务分表之外，我们还有一个常用的分表原则是：把调用频次高的放在一张表，调用频次低的放在另一张表

1.1 垂直拆分库

背景
经过业务的不断丰富和扩张，单库中可能存在多个业务领域的表。比如用户、订单、资产、积分 、财务报表 … 经过很多迭代部分表无人识别，梳理耗时费力
处理
以下图为例，按业务领域对单库进行拆分

拆分后每个领域只用关注自己相关的表，职责更单一了，维护也更方便了

垂直分库分表

可以将两者结合起来，例如有些财务系统，需要按月份和年份汇总，所有用户的资金

每年都有个单独的数据库，每个数据库中，都有12张表，每张表存储一个月的用户资金数据

水平拆分

背景：
应用刚上线时，只是主从或主备模式的单库，库中存放了对应的业务表。
随着用户量上升，当前的模式已经无法满足对数据库吞吐量的要求，主要是数据库请求 session 数量的限制导致。

通过对逻辑分析发现，写少读多，读写分离即可解决
读写分离
可以将写db 放在主库，读操作放在从库。主库写操作完成时，通过数据到从库。【由于网络原因有一定延时】
可以 一主多从，当主库宕机后，从库可以被选举为 master 继续工作

水平分库

背景：
上面的读写分离方案确实可以解决读请求大于写请求时，导致master节点扛不住的问题。但如果某个领域，比如：用户库。如果注册用户的请求量非常大，即写请求本身的请求量就很大，一个master库根本无法承受住这么大的压力。
处理：
以用户库为例，将用户库拆分为多个结构相同的库

每个库的表结构是一模一样的，只有存储的数据不一样，这样也可以解决session 不足的问题

水平分表

背景：
用户请求量上来了，带来的势必是单表的数据量上升，即使做了分库，也可能出现单表 几千万行的问题。此时就算做了索引也达到了索引的效益边界。单表的数据量应该尽量控制在1000万以内，性能是最佳的。
处理：
以用户表为例，拆分 用户表 为 用户表_n

每张表的表结构是一模一样的，只是存储的数据不一样。

水平分库分表

背景：
用户量大，单表数据量也大
处理：
图中将用户库拆分成了三个库，每个库都包含了四张用户表

如果有用户请求过来的时候，先根据用户id路由到其中一个用户库，然后再定位到某张表。

路由的算法挺多：
根据id 取模 ，比如：id=7，有4张表，则7%4=3，模为3，路由到用户表3。
给id指定一个 区间范围 ，比如：id的值是0-10万，则数据存在用户表0，id的值是10-20万，则数据存在用户表1。
一致性hash算法