分库分表问题及处理方案

一、为什么要进行分库分表

当MySQL单表数据量过大，比如超过5千万条的时候，读写性能变得很差。而且常规的优化手段已经不起作用了，比如：SQL调优、添加索引、主从复制、读写分离。这时候就需要用到MySQL终极优化方案 — 分库分表。

二、怎么判断项目是需要分库还是要分表？是先分库还是先分表

• 当数据库的QPS过高，数据库连接数不足的时候，就需要分库。（比如一个库的连接数支持2K，分成两个库就能支持4K）
• 微服务架构中，为了业务隔离，一般也做分库处理。
• 当单表数据量过大，读写性能较差，就需要分表。
• 当两者都有的时候，就需要分库分表。

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

三、分库分表有哪些拆分方案

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

• 垂直分库：不同的业务拆分到不同的数据库（比如微服务分库）。
• 水平分库：单张表QPS过高，把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。（解决了单库大数据，高并发的性能瓶颈）
• 垂直分表：把长度较大或者访问频次较低的字段，拆分到扩展表中。
• 水平分表：单表数据量过大时，按照订单ID拆分到多张表中。

 

                                                                        垂直分库

                                                                         

                                                                        垂直分表

四、分库分表的缺点及解决方案

4.1 缺点

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

• 垂直分表： 本来一张表能查出来的数据，现在需要多张表join关联查询，增加复杂度。

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

4.2 解决方案

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

2、多表分页查询问题：
这个处理起来就很需要技术含量了，比如：订单表按照订单ID分片，(order_id % 128)，分成了128张表。同一个用户的订单散落在不同的表，用户想查询自己的订单，根本无法做到分页查询。难道一次全部查询该用户的所有订单，然后做内存分页，多大的机器内存都让你搞挂。

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

4.2.1 如果商户想要分页查看自己店铺的订单怎么办？

那就把订单再冗余存储一份，按照店铺ID分片，(shop_id % 128)。不过由于商户数量较少，可以搞个异步线程往商户订单分片表同步。

4.2.2 订单按照用户ID分片后，发生数据倾斜怎么办？

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

五、跨库事务问题

  

                                                               跨库事务问题

下一个订单需要调用多个服务，只能使用分布式事务。 分布式事务的实现非常复杂，常用的有以下几种解决方案：

• 二阶段提交
• TCC
• 本地消息表
• MQ事务消息
• 分布式事务中间件