业务实战 | 如何设计分库分表策略

最新推荐文章于 2022-10-08 22:34:05 发布

程序员十一郎

最新推荐文章于 2022-10-08 22:34:05 发布

阅读量259

点赞数

文章标签： java

本文链接：https://blog.csdn.net/m0_68103666/article/details/124254735

版权

本文探讨了分库分表的原因、作用和定制策略。当单表数据量过大导致查询效率降低和系统假死时，需要考虑分库分表。通过实例分析了分库分表的调整方法，强调了策略设计应尽量避免复杂查询，同时介绍了数据分片策略，如取模分片、按时间范围分片，并提出了结合两者的方法。最后讨论了主键生成策略和绑定表的重要性。

摘要由CSDN通过智能技术生成

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

先将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，就要考虑分库分表。

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

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

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

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

关于数据分片策略:

分库策略：将核心

关注