MySQL深度分页(千万级数据量如何快速分页)(2)-木庄网络博客

在此先介绍一下执行计划Extra列可能出现的值及含义：

Using where：表示优化器需要通过索引回表查询数据。
Using index：即覆盖索引，表示直接访问索引就足够获取到所需要的数据，不需要通过索引回表，通常是通过将待查询字段建立联合索引实现。
Using index condition：在5.6版本后加入的新特性，即大名鼎鼎的索引下推，是MySQL关于减少回表次数的重大优化。
Using filesort:文件排序，这个一般在ORDER BY时候，数据量过大，MySQL会将所有数据召回内存中排序，比较消耗资源。

再看看上图，同样的语句，只因为偏移量不同，就造成了执行计划的千差万别（且容我小小的夸张一下）。第一条语句LIMIT 100,6type列的值是range，表示范围扫描，性能比ref差一个级别，但是也算走了索引，并且还应用了索引下推：就是说在WHERE之后的下单时间删选走了索引，并且之后的ORDER BY也是根据索引下推优化，在执行WHERE条件筛选时同步进行的（没有回表）。
而第二条语句LIMIT 1000000,6压根就没走索引，type列的值是ALL，显然是全表扫描。并且Extra列字段里的Using where表示发生了回表，Using filesort表示ORDER BY时发生了文件排序。所以这里慢在了两点：一是文件排序耗时过大，二是根据条件筛选了相关的数据之后，需要根据偏移量回表获取全部值。无论是上面的哪一点，都是LIMIT偏移量过大导致的，所以实际开发环境经常遇到非统计表量级不得超过一百万的要求。

优化

原因分析完了，那么LIMIT深度分页在实际开发中怎么优化呢？这里少侠给两点方案。
一是通过主键索引优化。什么意思呢？就是把上面的语句修改成：

SELECT * FROM cps_user_order_detail d WHERE d.id > #{maxId} AND d.order_time>'2020-8-5 00:00:00' ORDER BY d.order_time LIMIT 6;

如上代码所示，同样也是分页，但是有个maxId的限制条件，这个是什么意思呢，maxId就是上一页中的最大主键Id。所以采用此方式的前提：1）主键必须自增不能是UUID并且前端除了传基本分页参数pageNo,pageSize外，还必须把每次上一页的最大Id带过来，2）该方式不支持随机跳页，也就是说只能上下翻页。如下图所示是某知名电商中的实际页面。

二是通过Elastic Search搜索引擎优化（基于倒排索引），实际上类似于淘宝这样的电商基本上都是把所有商品放进ES搜索引擎里的（那么海量的数据，放进MySQL是不可能的，放进Redis也不现实）。但即使用了ES搜索引擎，也还是有可能发生深度分页的问题的，这时怎么办呢？答案是通过游标scroll。关于此点这里不做深入，感兴趣的可以做研究。

小结

写这篇博客是因为前段时间在开发中真实经历到了，并且之前在字节面试中确实也和面试官探讨了一番。知道LIMIT的限制以及优化，在面试中能提到是加分项，不能说到MySQL优化就是建索引，调整SQL（实际上在真实开发中这两种优化方案的成效微乎其微）。毕竟MySQL优化那么牛X的话，就不会有那么多中间件产生了。

到此这篇关于MySQL深度分页(千万级数据量如何快速分页)的文章就介绍到这了,更多相关MySQL 深度分页内容请搜索

更多相关Mysql内容来自木庄网络博客

标签：Mysql

返回前面的内容