（1）前序：
    介绍第二个案例拓展，也就是一般互联网公司的订单系统是如何做分库分表的，既然要说订单系统的分库分表，那就说说为什么订单需要分库分表，其实最关键的一点就是分析一下订单系统的 数据量有多大？这个就得看公司的具体情况了。
    比如说一个小型互联网公司，如果是涉及到电商交易，肯定每天都会有一些订单进来的，那么比如小型互联网公司j假设有500万的注册用户，每天日活的用户有多少人？就是500万注册用户， 并不是每天都来光顾的，按照28法则，500万的注册用户，每天最多20%的用户来光顾，也就是会来访问你的app/小程序/网站，也就是100万的日活用户，但是这个日活恐怕很多公司都达不到，所以一般 靠谱点就是他是10%的用户每天都来光顾你，算下来就是平均每个注册用户10天会来光顾你一次，这就是50万的日活用户。
    但是50万日活用户仅仅来看看而已，那么有多少人来买你的东西？这个购买比例就更低了，基本上这种小型互联网公司每天就做个1万订单，或者几万订单，这就已经相当不错了，就以保守1万 来算，那就是每天订单表新增1万左右，每个月是新增30万，每年360万数据。看着不是很大，但是按照我们上次说的，一般建议单表控制在千万以内，尽量是100万到500万之间，如果控制在几十万是 最好的。
    所以分析发现，哪怕是小互联网公司，订单数据量也不少，因为订单这种数据和用户数据是不同的，用户数据一般不会增长过快，而且很快会达到一个天花板，就不怎么再涨了，但是订单 数据每天都有增量的，特点不同。 所以这个订单表，按一年360万数据增长来计算，最多3年就到千万级大表了，这个就绝对会导致你涉及订单的操作，速度挺忙的。这里介绍两个亲身体验的订单这块的案例。
    一个是某社保类APP，而且一定是没有做任何的分表，导致每次对自己的订单进行查询的时候，基本都是秒级，每次打开订单页面都很慢，有时候甚至达到两三秒的样子，体验很差。 另一个是某个企业银行APP，企业银行是可以运训财务提交打款申请的，然后有人审批，但是很明显对这类申请和审批的数据表，没做过分库分表的处理，导致数据日积月累的增加，每次申请 和审批的查询界面都很慢，起码要卡1s以上的时间，这个体验也很不好。


    所以说，基本上这类订单表即使是小互联网公司，按分库分表几乎是必须做的，那么怎么做？订单表一般在拆分的时候往往要考虑三个维度，一个是必然按照订单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去分库分表 里找订单完整数据。

    （2）总结：
    其实分库分表的玩法基本都是这套路，按照业务id分库分表，建立索引映射表同时进行分库分表，数据同步到ES到复杂搜索，基本这套玩法就可以保证分库分表场景下，各种业务功能都能支撑。