转载自：https://mp.weixin.qq.com/s/ZghGRZ7WFvkUkU1LOiXPqg
最近大白接手了一个商户订单查询系统，查询某个商户的订单记录时，有点慢，尤其是点分页的时候，越翻越慢。刚接手领导就让大白优化这玩意，说实话大白也忍受不了查询慢，于是开始着手优化这个订单查询功能。
话说查询慢倒也正常，一个商户一天的订单少的有几万，多的有上百万的，这些商户也太挣钱了，扯远了，开始优化。数据库是mysql，版本5.7，查询按时间倒序排列，分页limit，查询条件都已加索引，商户只能查自己的数据。
根据以上分析，结合大白的优化经验，优化查询千万条，按需查询第一条。当前的查询条件默认是按当天作为起止时间去查询，这个时候一个每天的订单量少至几万多至几百万不等，618的时候有的商户订单可能到千万大关。
大白今天就不截图了，下面直接用文字表达我的两种优化思路。
1.每个商户的订单按序号自增生成流水，类似自增的id。
由于商户太多，不再借助数据库生成。大白使用单一微服务按商户号生成自增id，这个id是主键之外的候选键。大白为这个候选键加上索引，每次查询大白会根据上一次查询的最小id，并且根据最小id减去100的值筛选，进行范围查询，显然每次最多load出100条数据，分页展示10条或20条，比较轻松。
这里再说下大白的微服务生成流水号，是借助ConcurrentHashMap和AtomicLong，按照商户号为key递增生成，实现比较容易。当然了借助分布式redis更简单安全可靠一些，因为大白那时还处在memcached时代，所以选择自己构建了一个微服务。这是大白之前的设计，现在是改造历史项目，大白这招并不适用，没有Mr.Right，只是看谁更fit一些。
2.既然订单很多，不妨在分页的时候，缩小时间范围。
查询慢是因为每次加载的数据太多，前台页面又需要分页，所以很多数据加载之后被无情废弃，白白浪费了系统资源。现在商户大多是按照当日时间来查询，分页的时候大白会取上一页时间最小值，并且最小时间减去5分钟的值去筛选，进行范围查询，显然每次只查询5分钟的数据压力要减轻很多，然后再分页展示10条或20条。
这里需要注意，可能阈值5分钟需要按实际情况去调整。个别不够10条的，大白都做了2次查询，继续向下injust。这里大白想表达的除了缩小时间范围，其实查询拆分也是常见的做法，以目前的数据库服务查询性能及网络带宽，分多次查询根本不影响你的性能。
总结，许多优化不仅可以从问题本身出发，还可以等量替换解决。大白能力有限，欢迎批评指正。
这个大白的技术还可以哈，感觉不错给这个大白加个关注，阅读更多文档吧。
