• SQL优化之深分页


    SQL优化之深分页

    我们都知道,大型项目中的SQL语句,应该尽量避免深分页。

    那么问题就来了:

    1. 深分页的性能差在哪?
    2. 什么方案能避免深分页呢?

    什么是深分页

    深分页,即SQL查询过程中,使用的页数过深,数据库执行的过程中,需要遍历前面很多数据并跳过后,才返回数据的过程。

    这种情况会导致SQL查询变慢;

    深分页的性能问题

    上面介绍了深分页的描述,那下面具体看下深分页的性能问题。

    1、覆盖索引
    select uid from user_info limit 100, 10;
    select uid from user_info limit 10000, 10;
    select uid from user_info limit 1000000, 10;
    select uid from user_info limit 2000000, 10;
    

    在这里插入图片描述

    在查询语句能够命中覆盖索引的情况下,可以看到查询范围在[2000000,2000010]的10条数据,耗时近200ms。对于线上千万级的数据表来说,即使查询不需要回表,那也是妥妥的慢查询,

    2、非覆盖索引
    select * from user_info limit 100, 10;
    select * from user_info limit 10000, 10;
    select * from user_info limit 1000000, 10;
    select * from user_info limit 2000000, 10;
    

    在这里插入图片描述

    同样的查询范围,对于需要回表的SQL查询,耗时提高了近4倍,查询效率更低。

    深分页的优化

    1、Inner Join

    使用Inner Join提高深分页,原理是减少查询时的回表次数;

    利用id的有序性,通过子查询获取到指定记录的一组id,再查询id对应的记录。

    select * from user_info limit 2000000, 10;
    select * from user_info
    inner join (
     select uid from user_info limit 2000000, 10 
    ) as sub on sub.uid = user_info.uid;
    

    在这里插入图片描述

    2、边界记录

    上面的Inner Join 用到了子查询,对性能还是有一定的影响;

    如果业务中的页遍历是顺序的,没有跨页的情况,那可以考虑对每次查询接结果,记录返回的最大id,作为下一次查询的开始id。

    这样就能避免子查询的使用,同时减少回表次数。

    select * from user_info where id >= 2000010 limit 10;
    

    在这里插入图片描述

    总结

    对于深分页问题,无论是使用Inner Join、还是记录上一个id,核心思路都是要降低回表次数。

  • 相关阅读:
    设计模式-Adapter
    【Android】WebView请求HttpRequest和HttpResponse
    HyperLynx(三十)高速串行总线仿真(二)
    systemd-modules-load.service
    5.自定义地形及影像
    C++ 中的 this 指针
    【接口测试】Postman(二)-Postman Echo
    Java项目源码基于JavaWeb实现的停车场车位收费管理系统
    flink1.18.0 sql-client报错
    RabbitMQ-04(SpringBoot整合RabbitMQ,基本使用)
  • 原文地址:https://blog.csdn.net/alpha_xia/article/details/140365925