百亿级数据分表后怎么分页查呢？

当营业规模到达必然规模之后，像淘宝日订单量在5000万单以上，美团3000万单以上。数据库面临海量的数据压力，分库分表就是必需停止的操做了。而分库分表之后一些常规的查询可能城市产生问题，最常见的就是好比分页查询的问题。一般我们把分表的字段称做shardingkey，好比订单表根据用户ID做为shardingkey，那么若是查询前提中不带用户ID查询怎么做分页？又好比更多的多维度的查询都没有shardingkey又怎么查询？

一般我们数据库的主键都是自增的，那么分表之后主键抵触的问题就是一个无法制止的问题，最简单的法子就是以一个独一的营业字段做为独一的主键，好比订单表的订单号必定是全局独一的。

常见的散布式生成独一ID的体例良多，最常见的雪花算法Snowflake、滴滴Tinyid、美团Leaf。以雪花算法举例来说，一毫秒能够生成4194304多个ID。

第一位不利用，默认都是0，41位时间戳切确到毫秒，能够包容69年的时间，10位工做机器ID高5位是数据中心ID，低5位是节点ID，12位序列号每个节点每毫秒累加，累计能够到达2^12 4096个ID。

第一步，分表后要怎么包管订单号的独一搞定了，如今考虑下分表的问题。起首按照本身的营业量和增量来考虑分表的大小。

举个例子，如今我们日单量是10万单，预估一年后能够到达日100万单，按照营业属性，一般我们就撑持查询半年内的订单，超越半年的订单需要做归档处置。

那么以日订单100万半年的数量级来看，不分表的话我们订单量将到达100万X180=1.8亿，以那个数据量级部门表的话必定单表是扛不住的，就算你能扛RT的时间你也底子无法承受吧。按照经历单表几百万的数量关于数据库是没什么压力的，那么只要分256张表就足够了，1.8亿/256≈70万，若是为了保险起见，也能够分到512张表。那么考虑一下，若是营业量再增长10倍到达1000万单每天，分表1024就是比力适宜的选择。

通过火表加上超越半年的数据归档之后，单表70万的数据就足以应对大部门场景了。接下来对订单号hash，然后对256取模的就能够落到详细的哪张表了。

那么，因为独一主键都是以订单号做为根据，以前你写的那些按照主键ID做查询的就不克不及用了，那就涉及到了汗青一些查询功用的修改。不外那都不是事儿对吧，都改成以订单号来查就行了。那都不是问题，问题在我们的题目说的点上。

说了半天，总算到了正题了，那么分表之后查询和分页查询的问题怎么处理？

起首说带shardingkey的查询，好比就通过订单号查询，不管你分页仍是怎么样都是能间接定位到详细的表来查询的，显然查询是不会有什么问题的。

若是不是shardingkey的话，上面举例说的以订单号做为shardingkey的话，像APP、小法式那种一般都是通过用户ID查询，那那时候我们通过订单号做的sharding怎么办？良多公司订单表间接用用户ID做shardingkey，那么很简单，间接查就完了。那么订单号怎么办，一个很简单的法子就是在订单号上带上用户ID的属性。举个很简单的例子，本来41位的时间戳你觉得用不完，用户ID是10位的，订单号的生陈规则带上用户ID，落详细表的时候按照订单号中10位用户ID hash取模，如许无论按照订单号仍是用户ID查询效果都是一样的。

当然，那种体例只是举例，详细的订单号生成的规则，几位，包罗哪些因素按照本身的营业和实现机造来决定。

好，那么无论你是订单号仍是用户ID做为shardingkey，根据以上的两种体例都能够处理问题了。那么还有一个问题就是若是既不是订单号又不是用户ID查询怎么办？最曲不雅的例子就是来自商户端或者后台的查询，商户端都是以商户或者说卖家的ID做为查询前提来查的，后台的查询前提可能就更复杂了，像我碰着的有些后台查询前提能有几十个，那怎么查？？？别急，接下来分隔说B端和后台的复杂查询。

现实中实正的流量大头都是来自于用户端C端，所以素质上处理了用户端的问题，那个问题就解了大半，剩下来自商户卖家端B端、后台撑持运营营业的查询流量其实不会很大，那个问题就好解。

针对B端的非shardingkey的查询有两个法子处理。

双写，双写就是下单的数据落两份，C端和B端的各自保留一份，C端用你能够用单号、用户ID做shardingkey都行，B端就用商家卖家的ID做为shardingkey就好了。有些同窗会说了，你双写不影响性能吗？因为关于B端来说轻细的延迟是能够承受的，所以能够采纳异步的体例去落B端订单。你想想你去淘宝买个工具下单了，卖家略微延迟个一两秒收到那个订单的动静有什么关系吗？你点个外卖商户晚一两秒收到那个订单有什么太大影响吗？

那是一个处理计划，别的一个计划就是走离线数仓或者ES查询，订单数据落库之后，不管你通过binlog仍是MQ动静的都形式，把数据同步到数仓或者ES，他们撑持的数量级关于那种查询前提来说就很简单了。同样那种体例必定是略微有延迟的，但是那种可控范畴的延迟是能够承受的。

而针对办理后台的查询，好比运营、营业、产物需要看数据，他们天然需要复杂的查询前提，同样走ES或者数仓都能够做得到。若是不消那个计划，又要不带shardingkey的分页查询，兄弟，那就只能扫全表查询聚合数据，然背工动做分页了，但是如许查出来的成果是有限造的。

好比你256个片，查询的时候轮回扫描所有的分片，每个片取20条数据，最初聚合数据手工分页，那一定是不成能查到全量的数据的。

分库分表后的查询问题，关于有经历的同窗来说其实那个问题都晓得，但是我相信其实大部门同窗做的营业可能都没来到那个数量级，分库分表可能都停留在概念阶段，面试被问到后就不知所措了，因为没有经历不晓得怎么办。

分库分表起首是基于现有的营业量和将来的增量做出判断，好比拼多多那种日单量5000万的，半年数据得有百亿级别了，那都得分到4096张表了对吧，但是现实的操做是一样的，关于你们的营业分4096那就没有需要了，按照营业做出合理的选择。

关于基于shardingkey的查询我们能够很简单的处理，关于非shardingkey的查询能够通过落双份数据和数仓、ES的计划来处理，当然，若是分表后数据量很小的话，建好索引，扫全表查询其实也不是什么问题。