分库分表策略设计方式及思路梳理

一、什么是分库分表？什么时候要分库分表？   

先将tulingmall-order的jdbc数据源调整到本地，然后在本地数据库中，已经插入了20+W的订单数据，全都是Monkey用户插入的。

调整方法：

1、在启动类上排除掉SpringBootConfiguration.class，这个是ShardingSphere进行分库分表的配置类。@SpringBootApplication(exclude = {SpringBootConfiguration.class})

2、调整配置文件，打开application.yml中的datasource配置。

然后在前端tuling-front用Monkey/123用户登录，进入"我的订单"页面，这个页面可以查询到所有的订单。--页面没有分页，但是能够加载更多的订单。简单分析下这个查询订单的SQL：

查第一页会非常快，只要0.002秒。但是往后翻页时，效率会越来越低。当翻页翻到 10000,10时，执行时间需要3秒多。100000,10时执行时间需要4秒多。

查询会耗时2秒多。而简单执行下面这个SQL语句，会要消耗7秒多。

select * from (

select 1 from oms_order o LEFT JOIN oms_order_item ot on o.id = ot.order_id

) t limit 200000,10

这个时长如果需要响应到页面上，那就已经是无法忍受了。这还只是一个简单的查询，并且返回的数据其实还不多。如果数据更多(比如导出)，查询更复杂，并发量更大，那消耗的时间会更长。

单表数据量太大带来的问题还不止是查询变慢，如果数据更多，还很容易造成系统假死。如果我们的订单页面不断的加载订单，那浏览器也会崩溃。

二、分库分表的作用   

• 加大存储，

• 提升查询效率，

• 提升数据库的并发能力。

阿里的开发规范中建议预估三年内单表数据量上500W，或者大小上2G，就要考虑分库分表。

三、定制分库分表策略    

定制分库分表策略的注意点：

• 分库分表一般要在开发之前设计，尽量避免临时设计。只针对最核心的表。

• 分库分表后，对表的查询必须足够简单，不要有跨表，跨库的复杂查询。

• 分库和分表尽量同时进行，分库可以分担网络压力。

关于数据分片策略:

• 分库策略：将核心的订单表和订单物品表从业务库中移出来，单独放到一个库。我们分成两个库。分散网络压力。

• 分表策略：在每个库分两个表，尽量将数据平均的分配到这四个表中。分散单表查询压力。

考虑的问题：

• 取模分片能够将数据分配得尽量的平均，但是不利于扩展。

• 按范围分片便于扩展但是他的数据分布又不够均匀。

• 是不是可以定制一种分片策略，将这两种分片策略结合起来？比如大尺度上按范围分片，但是在每个数据范围内，使用取模分片。这种分片策略要如何在ShardingSphere中实现？提供思路，留给大家自己实现。

• 1、回顾下ShardingSphere的几种分片策略实现方式：inline, standard, complex, hint。

• 2、两个库，四个表。要如何将数据分配均匀？

• 3、如何定制适合业务场景的数据分片策略？

• 有哪些常用的数据分片策略？取模分片、按时间范围分片、按业务要素(如地区、前缀等)分片……