了解百亿级数据分表后的 分页查询

了解百亿级数据分表后的分页查询

随着业务规模的不断扩大，对于一些涉及大量数据的系统而言，分库分表已经成为必须的操作。分表之后，很多常规的查询都会出现问题，尤其是分页查询。分表的字段通常被称为shardingkey，比如订单表按照用户ID作为shardingkey，那么如果查询条件中不带用户ID查询怎么做分页？更多维度的查询都没有shardingkey又怎么查询呢？这就是分表后查询面临的问题。

首先，要保证唯一性问题。一般数据库的主键都是自增的，但是在分表之后主键冲突就是无法避免的。最好的办法是以一个唯一的业务字段作为主键，比如订单表的订单号。

接下来考虑分表的问题。分表的大小需要根据业务量和增量来决定。举个例子，如果日单量是10万单，预估一年后可以达到日100万单，一般来说我们只支持半年内的订单。以日订单100万半年的数量级来看，如果不分表的话，订单量将达到1800万，单表根本无法承受。一般单表支持几百万的数据量是没有问题的，那么只要分256张表就足够了，如果要保险起见，也可以分到512张表。如果业务量再增长10倍达到1000万单每天，分表1024就是比较合适的选择。分表之后，对于一些常规SQL查询将无法使用，因为唯一主键都是以订单号为依据。但这个问题并不大，只需要将历史查询功能修改为以订单号为查询依据即可。

针对C端的查询，带shardingkey的查询都是没有问题的。如果不是shardingkey，而是以用户ID为查询条件，可以直接对订单表按照用户ID进行sharding，或者在订单号上带上用户ID的属性。对于B端和后台的查询，你可以采取异步落B端订单，或者将订单数据同步到数仓或ES上。

总的来说，对于分库分表后的查询问题，要根据现有业务量和未来增量做出选择，解决唯一性和分表查询问题，以及针对B端和后台的查询，可以采取异步落单和同步到ES等解决方案。

扫码添加UTHEME微信为好友

· 分享WordPress相关技术文章，主题上新与优惠动态早知道。
· 微信端最大WordPress社群，限时免费入群。