当业务规模达到?定规模之后，像淘宝?订单量在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做查询的就不能?了，这就涉及到了历史?些查询功能的修改。不过这都不是事?对吧，都改成以订单号来查就?了。这都不是问题，问题在我们的标题说的点上。
C端查询
说了半天，总算到了正题了，那么分表之后查询和分?查询的问题怎么解决？?先说带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的?案来解决，当然，如果分表后数据量很?的话，建好索引，扫全表查询其实也不是什么问题。
