最近做一个需求，业务需要一个查看并能导出订单的页面。但分析历史订单数据发现公司每个月都有六七百万的订单数据，如果碰到大促可能就有上千万，单靠mysql查效率有点差，但偏偏部门还没有可用的搜索引擎，需求也比较紧急，去申请资源再搭建时间来不及。后来想了个方案，将订单数据同步过来按月分表，虽然查数据只能查月内数据，但也能满足基本使用，等后期再用ES优化。
实现与优化公司用的通用的一套分页中间件，所以我就先按普通的写法实现了一版，结果测试后发现效率是真的不行，一次查询要48秒。
一方面是数据量比较大，还有一个就是因为按照权限，每个账号只能查询绑定的主播订单，所以主播用了in查询，如果主播很多的话这查询效率就慢的难以接受了。
我尝试了一下查看单个主播，发现速度其实也还行，只需两秒。
总体来说查的确实慢，所以按照行业经验优化了一版
【推荐】利用延迟关联或者子查询优化超多分页场景。 说明：MySQL并不是跳过offset行，而是取offset+N行，然后返回放弃前offset行，返回N行，那当offset特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行SQL改写。 正例：先快速定位需要获取的id段，然后再关联： SELECt a.* FROM 表1 a, (select id from 表1 where 条件 LIMIT 100000,20 ) b where a.id=b.id
测试了一下，效率提升很明显，快了一倍。
如果只查单个主播只需0.7秒
虽然速度是快了一倍，但刚进页面默认加载所有主播订单时还是需要21秒的时间，肯定还是无法接受。
但数据库改加的索引也已经加了，sql也进行了优化，不用ES按现有条件确实到了瓶颈。
后来和产品商量后从需求的角度进行了优化，给了两个方案
1.刚进页面默认不查询，用户自行选择筛选条件后再查询。
2.按主播排序，默认只展示第一个主播的订单
经过评估后采用了第二个方案，毕竟一进页面空空如也确实不太友好，而且业务通常也是根据主播商品维度去查看订单，没有查看所有订单的需求。
至此这个超大分页优化问题得到了解决，但还是有局限性。所以在有条件的情况下还是用搜索引擎比较好。
