如何确定历史表分库分表的分片路由规则最优解？

本文共计3527个文字，预计阅读时间需要15分钟。

选择最佳分区路径规则前，先明确关闭。我相信这篇文章应涵盖所有讲过的人，包括你们的分割模式。外部文章基本教你如何从零开始。

分库分表之历史表如何选择最佳分片路由规则 前言

先别急着关闭,我相信这篇文章应该是所有讲分表分库下的人都没有和你们讲过的一种分片模式,外面的文章基本上都是教你如何从零开始分片,现在我将讲解的是如何从1+开始分片

项目地址

• github地址 github.com/dotnetcore/sharding-core
• gitee地址 gitee.com/dotnetchina/sharding-core

背景

首先我相信很多人使用分表分库一定有这么一个情况,就是目前我们的系统有一张表可能会非常的庞大,然后希望通过分片技术将其进行水平拆分,但是如何拆分或者说如何拆分可以保证让目前的数据性能达到最优解，是一个很值得探讨的问题。

这边简单举一个例子，譬如我们的订单表,目前我们的订单表可能已经达到一定的数量级了比如百万或者千万级别了，可能光是简单的查询性能是很高的，但是新增订单可能就没这么乐观了，随着索引的增多新增的数目也会不断地变慢，不仅仅是查询一个维度迫使你选择分表。
基于这个简单的案例我们来延伸一下如何水平拆分成为目前最关键的一个问题。

按月份表

这边我们如果将订单表按月进行水平分表那么我们可以了解到哪怕是随着时间的推移,数据库的瓶颈也会慢慢的变成容量的瓶颈了而不仅仅是单表的上限了。

假设我们这边的订单是从2016年开始的，一直到2022年3月我们发现订单表可以分成近70张表,而且针对分片我们有个天然的优势就是按时间分片可以拥有顺序查询这一特性，所以说这么来分片将是一个比较完美的实现

但是随着系统的运行我们发现这种分片方式虽然看着比较完美，但是存在一个很严重的问题就是数据的分布不均匀,因为可能系统刚上线那段时间我们的系统使用量并不是那么多，导致了系统内部的订单数量不会那么的多，所以虽然我们把订单表按月来分了，但是之前的历史数据因为使用量的原因导致按月分表的每张表里面可能拥有的数据很少很少。