mysql分库分键值表映射案例分析

业务开发势必会遇到分表分库，列如订单表，朋友圈数据表这种，随着时间增长，势必会无限增长，这就逼着我们不得不按时间去进行水平分表，当你在后期维护的时候，你是否会遇到这种情况？例如：经过初步估算我们决定按着天分表，可是前期业务量并没有上来，导致一个表内的数据只有十几万，甚至更少？或者到了后期某个月或者某天，因为我们一个活动的开展，单子表单数据量激增至好几千万？这样势必会导致我们的资源浪费或者资源不足的情况。那我们改怎么办呢？

解决方案：

键值映射

首先说下，这是我想到的名词，不知道别家怎么定的，欢迎讨论！
先说资源浪费的情况，比如我们按天分表如：order_20210101，order_20210101，order_20210101,如果每个表中的数据都只有十几万的数据的话，我们是可以手动将他们进行合并，合并为order_202101，这样三张表的数据就合并到了一张表之中，表中的数据只有可能会修改，删除，查询，不会出现新增的情况了，我们原来查询的时候，是要通过订单号分析，得出订单所在的表的，才能对其进行操作查询，可现在我们通过分析，已经无法定位表的所在了，因为原表已经不存在了，怎么办？键值映射，我们可以维护一个键值表，通过分析订单号，如得到order_20210101，然后这个表名作为键，值为order_202101,这样在查询数据表的时候，我们实际上查询的是order_202101，通过这种方式，我们解决了单表数据量过低的麻烦，对于分库来说，也可以做响应的操作。

再来说下单表不够用了怎么办？比如双十一，单日数据激增！单表无法承载，我们肯定会想到把表再进行切分，列如，通过一致性hash取模，分成30张表，刚刚是单键值对，现在我们可以定义一个map 键还是order_20210101,值是一个map，map中有两个元素，一个是定义 键【type】值是hash，另一个是map 键值对出现， {“1”:order_20210101_1,“2”:order_20210101_2,…}，当我们通过订单号取模，得出对应表的位置，就可以对数据进行操作了（键值表一定要入库，可以通过缓存增加效率）。

总结：实际应用中，你还应该考虑到分库的情况，所以你的库也应该做键值映射，我们可以通过中一个插件的方式，来获取最终要操作的库和表！核心目标- 找到需要操作的表进行操作！！