分库与分表

为什么要分库分表？

分表

比如你单表都几千万数据了，你确定你能扛住么？绝对不行，单表数据量太大，会极大影响你的 sql执行的性能，到了后面你的 sql 可能就跑的很慢了。一般来说，就以我的经验来看，单表到几百万的时候，性能就会相对差一些了，你就得分表了。

分表就是把一个表的数据放到多个表中，然后查询的时候你就查一个表。比如按照用户 id 来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在 200 万以内。

分库

分库就是你一个库一般我们经验而言，最多支撑到并发 2000，一定要扩容了，而且一个健康的单库并发值你最好保持在每秒 1000 左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。

这就是所谓的分库分表。

---

如何对数据库如何进行垂直拆分或水平拆分的？

什么是水平拆分？

水平拆分的意思，就是把一个表的数据给弄到多个库的多个表里去，但是每个库的表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据。水平拆分的意义，就是将数据均匀放更多的库里，然后用多个库来抗更高的并发，还有就是用多个库的存储容量来进行扩容。

什么是垂直拆分

垂直拆分的意思，就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另外一个表里去。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。

两种分库分表的方式：

1.一种是按照 range 来分，就是每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了。

2.或者是按照某个字段hash一下均匀分散，这个较为常用。

range 来分，好处在于说，扩容的时候很简单，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了；缺点，但是大部分的请求，都是访问最新的数据。实际生产用 range，要看场景。

hash 分发，好处在于说，可以平均分配每个库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算 hash 值重新分配到不同的库或表

总结：

1.当数据库的QPS过高，数据库连接数不足的时候，就需要分库。
2.当单表数据量过大，读写性能较差，就需要分表。
3.当两者都有的时候，就需要分库分表。

至于先分库还是先分表？建议先分表，如果分表能解决问题，就不需要分库了，毕竟需要单独服务器资源，成本更高。

分库分表有垂直拆分和水平拆分。垂直拆分又有垂直分库、垂直分表。

1.垂直分库，不同的业务拆分到不同的数据库。
2.垂直分表，把长度较大或者访问频次较低的字段，拆分到扩展表中。
3.水平分表，单表数据量过大时，按照订单ID拆分到多张表中。

分库分表缺点

分库分表带来了低耦合、高性能的优点，可是缺点却是一大堆。

垂直分库：
不同库多表之间无法join关联查询，只能通过接口聚合，复杂度直线上升。 横跨多个数据库导致无法使用本地事务，数据强一致性就别想了，只能引入更为复杂的分布式事务，勉强实现数据的最终一致性，可用性直线下降。

垂直分表：
本来一张表能查出来的数据，现在需要多张表join关联查询，这不瞎耽误事。

水平分表：
多张表关联查询时，无法实现分页、排序功能。

解决方案

跨库查询问题：
采用字段冗余方案，比如订单表存储店铺ID、店铺名称，就不需要再查询商户数据库了。 不过这种方案要求冗余字段要很少变动，就算变动后，也能容忍返回旧数据。

多表分页查询问题：
这个处理起来就很需要技术含量了。 比如：订单表按照订单ID分片，(order_id % 128)，分成了128张表。

同一个用户的订单散落在不同的表，用户想查询自己的订单，根本无法做到分页查询。难道一次全部查询该用户的所有订单，然后做内存分页，多大的机器内存都让你搞挂。

想要实现用户订单分页查询，可以采用按照用户ID分片，(user_id % 128)，这样同一个用户的订单只会存储在一张表中，咋分页展示都行。

没有完美的分片方案，如果商户想要分页查看自己店铺的订单怎么办？
那就把订单再冗余存储一份，按照店铺ID分片，(shop_id % 128)。不过由于商户数量较少，可以搞个异步线程往商户订单分片表同步。

订单按照用户ID分片后，发生数据倾斜怎么办？
因为不同用户的订单量是不同的，一个爱好购物的小姐姐的订单量抵得上几十个老爷们。导致一张表数据几百条，另一张表数据量千万级，这该咋整？
做冷热数据分离，基础库只存储3个月内的订单，其他的移动到历史订单库。这个要跟产品商量好，3个月前的订单需要单独的查询页面。