MySQL：一线电商公司的订单系统是如何进程数据库设计的？

为什么订单需要分库分表

这里就先要分析一下订单系统的数据量了。那么订单系统的数据量有多大，这个就得看具体公司的情况了。

比如一个小型电商互联网公司，那么每天都会有一些订单进来。那么如果这家公司有500万注册用户，每条日活的用户会有多少人？意思是说，你500万注册用户，并不是每个人每天都来关顾你这里的。

即使按照28法则，500万注册用户，每天最多是20%的用户会过来关顾你这里，也就是说，大概100万的日活用户，但是这个日活比例恐怕很多公司都达不到，所以一般靠谱点也就10%的用户每条都会关顾你，算下来就是平均每个注册用户10天回来关顾你一次，这就是50万的日活用户。

但是这50万的日活用户仅仅是来看看而已，不一定会下单。基本上每天可能1w订单就不错了。

也就是说，这个互联网公司的订单表每天新增数据大概是1w左右，每个月新增大约30万数据，每年新增360w数据。这个数据量也不算大。

但是，一般建议单表控制在千万以内，尽量是100w到500w之间，如果控制在几十万是最好了

所以，分析下来，大家会发现，哪怕是小型互联网公司，订单数量也不少。因为订单这种数据和用户数据时不同的，你用户数据一般不会增长过快，而且很快会达到一个天花板，就不会再涨了，但订单数据每条都会增加，它们的特点是不同的。

所以这个订单表，即使按照一年360w的数据增长来算，最多3年就到千万级的大表了，这个就决定会导致涉及订单的操作变慢。

所以订单表，分库分表是必须要做的。

怎么做

订单表，一般在拆分的时候，需要考虑三个维度,

• 一个是必然要按照订单id为粒度去分库分表，也就是把订单id进行hash之后，对表数量进行取模然后把订单数据均匀分散到100~1000个表里去，再把这些表分散到多台服务器上

• 但是这里会有个问题，另外两个维度是用户端和运营端。用户端，就是用户可能要查自己的订单，运营端就是公司可能要查所有订单，那么怎么解决这类问题？

• 这个时候，可能按照（userid，orderid）这个表结构，去建立一个索引映射表

• userid和orderid的一一对应映射关系要放在这个表里，然后针对userid为粒度去进行分库分表，也就是对userid进行hash后取模，然后把数据均匀分散到很多索引映射表中，再把表放在很多数据库里

• 然后每次用户端拿出自己的App查询自己的订单，直接根据userid去hash然后取模路由到一个索引映射表，找到这个用户的orderid，这里当然可以做一个分页了。因为一般订单都是支持分页的，此时可以允许用户分页查询orderid，然后拿到一堆orderid了，再根据orderid去按照orderid粒度分库分表的表里提取订单完整数据。

• 对于运营端，一般都是要根据N多条件对订单进行搜索，这时可以把订单数据的搜索条件同步到ES里，然后用ES进行复杂搜索，找出一堆orderid，在根据orderid去分库分表里找订单完整数据。

总的来说，分库分表的玩法其实都是这种套路：按照业务id分库分表，建立索引映射表同时分库分表，数据同步到ES做复杂搜索。