如何解决mysql深度分页问题

目录
  • 1.基本分页:耗时0.019秒
  • 2.深度分页:耗时10.236秒
  • 3.深度ID分页:耗时0.052秒
  • 4.两步走深度分页:耗时0.049秒+0.017秒
  • 5.一步走深度分页:耗时0.05秒
  • 6.集成BeanSearcher框架
  • 7.万能优化技巧:索引
  • 总结

数据:单表数据25万条。

1.基本分页:耗时0.019秒

select * from cf_qb_info limit 0,20

2.深度分页:耗时10.236秒

select * from cf_qb_info limit 200000,20

3.深度ID分页:耗时0.052秒

提示:如果这一步很慢,count(1) 查询总数应该也会很慢-解决方式:请为主键加上unique索引。

-- 主键ID字段:NUMID
select NUMID from cf_qb_info limit 200000,20

4.两步走深度分页:耗时0.049秒+0.017秒

基于第三步的缺陷(只能查出ID信息),我们可以先查出分页数据的ID,在根据ID查询数据。

select NUMID from cf_qb_info LIMIT 200000,20
select * from cf_qb_info where NUMID in (
'330681650000202108180227345510',
'330681650000202108171031534500',
'330681650000202108190251532141',
'330681650000202108200246376830',
'330681650000202108210229398665',
'330681650000202108220236113895',
'330681650000202108230230034133',
'330681650000202108231017279739',
'330681650000202108231043456276',
'330681650000202108231051404340',
'330681650000202108240237397251',
'330681650000202108250221489228',
'330681650000202108250241536726',
'330681650000202108260253039326',
'330681650000202108270216016138',
'330681650000202108280234013754',
'330681650000202108290230029720',
'330681650000202108300255579204',
'330681650000202108310234184991',
'330681650000202109010237315937'
);

两步合成一步SQL耗时:11.9秒;这一步着实出乎了我的意料。

select * from cf_qb_info where NUMID in (

	select NUMID from (select NUMID from cf_qb_info LIMIT 200000,20) as t

);

鉴于这个结果:我们可以在程序里分成两步进行分页查询。

5.一步走深度分页:耗时0.05秒

这一步是对第四步的优化,毕竟两条SQL还需要码代码。利用join 两条SQL合成一条。

SELECT
	*
FROM
	cf_qb_info a
	JOIN ( SELECT NUMID FROM cf_qb_info LIMIT 200000, 20 ) b ON a.NUMID = b.NUMID

6.集成BeanSearcher框架

原理是使用了BeanSearcher的sql拦截器对SQL进行拦截改造。

①改造Bean

②注入Sql拦截器

package com.ciih.qbbs.config;

import cn.hutool.core.util.ReUtil;
import cn.hutool.core.util.StrUtil;
import com.baomidou.mybatisplus.annotation.TableId;
import com.ejlchina.searcher.SearchSql;
import com.ejlchina.searcher.SqlInterceptor;
import com.ejlchina.searcher.SqlSnippet;
import com.ejlchina.searcher.param.FetchType;
import org.springframework.stereotype.Component;

import java.lang.reflect.Field;
import java.util.List;
import java.util.Map;

/**
 * BeanSearcher的Sql拦截器:优化深度分页
 *
 * @author sunziwen
 */
@Component
public class SqlInterceptorImpl implements SqlInterceptor {
    @Override
    public <T> SearchSql<T> intercept(SearchSql<T> searchSql, Map<String, Object> paraMap, FetchType fetchType) {
        /**
         * 改造思路
         *
         * <>
         *     前:SELECT * FROM table1 t1 LIMIT 200000,20;
         *     后:SELECT * FROM table1 t1 JOIN ( SELECT id FROM table1 LIMIT 200000, 20 ) t99 ON t1.id = t99.id;
         * </>
         */

        Field[] fields = searchSql.getBeanMeta().getBeanClass().getDeclaredFields();
        String primaryColumnName = null;
        for (Field field : fields) {
            //这里使用了mybatis_plus的注解作为主键标识
            TableId tableId = field.getAnnotation(TableId.class);
            if (tableId != null) {
                if (!"".equals(tableId.value())) {
                    primaryColumnName = tableId.value();
                } else {
                    //驼峰转下划线
                    primaryColumnName = StrUtil.toUnderlineCase(field.getName());
                }
            }
        }
        //如果没有主键标识,则不能进行SQL优化。
        if (primaryColumnName == null) {
            return searchSql;
        }

        //正则表达式获取where之后语句
        List<String> limits = ReUtil.findAll("where[\\s\\S]*limit[ ]+[?]{1}[ ]*,[ ]+[?]{1}", searchSql.getListSqlString(), 0);

        //如果不分页,则不进行SQL优化,即语句中没有limit关键字不优化。
        if (limits.size() == 0) {
            return searchSql;
        }

        //表名小片段
        SqlSnippet tableSnippet = searchSql.getBeanMeta().getTableSnippet();
        //合成子查询SQL
        String inSql = "JOIN ( SELECT " + primaryColumnName + " FROM " + tableSnippet.getSql() + " " + limits.get(0) + " ) t99 ON t1." + primaryColumnName + " = t99." + primaryColumnName + ";";
        //合成整条SQL
        String replace = searchSql.getListSqlString().replace(limits.get(0), inSql);
        //替换
        searchSql.setListSqlString(replace);
        return searchSql;
    }
}

7.万能优化技巧:索引

总结

以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。

(0)

相关推荐

  • 提高MySQL深分页查询效率的三种方案

    开发经常遇到分页查询的需求,但是当翻页过多的时候,就会产生深分页,导致查询效率急剧下降.有没有什么办法,能解决深分页的问题呢?本文总结了三种优化方案,查询效率直接提升10倍,一起学习一下. 开发经常遇到分页查询的需求,但是当翻页过多的时候,就会产生深分页,导致查询效率急剧下降. 有没有什么办法,能解决深分页的问题呢? 本文总结了三种优化方案,查询效率直接提升10倍,一起学习一下. 1. 准备数据 先创建一张用户表,只在create_time字段上加索引: CREATE TABLE `user`

  • 深入了解MySQL中的慢查询

    目录 一.什么是慢查询 二.慢查询的危害 三.慢查询常见场景 总结 一.什么是慢查询 什么是MySQL慢查询呢?其实就是查询的SQL语句耗费较长的时间. 具体耗费多久算慢查询呢?这其实因人而异,有些公司慢查询的阈值是100ms,有些的阈值可能是500ms,即查询的时间超过这个阈值即视为慢查询. 正常情况下,MySQL是不会自动开启慢查询的,且如果开启的话默认阈值是10秒 # slow_query_log 表示是否开启 mysql> show global variables like '%slo

  • MySQL深度分页(千万级数据量如何快速分页)

    目录 前言 案例 优化 小结 前言 后端开发中为了防止一次性加载太多数据导致内存.磁盘IO都开销过大,经常需要分页展示,这个时候就需要用到MySQL的LIMIT关键字.但你以为LIMIT分页就万事大吉了么,Too young,too simple啊,LIMIT在数据量大的时候极可能造成的一个问题就是深度分页. 案例 这里我以显示电商订单详情为背景举个例子,新建表如下: CREATE TABLE `cps_user_order_detail` ( `id` bigint(20) unsigned

  • 如何解决mysql深度分页问题

    目录 1.基本分页:耗时0.019秒 2.深度分页:耗时10.236秒 3.深度ID分页:耗时0.052秒 4.两步走深度分页:耗时0.049秒+0.017秒 5.一步走深度分页:耗时0.05秒 6.集成BeanSearcher框架 7.万能优化技巧:索引 总结 数据:单表数据25万条. 1.基本分页:耗时0.019秒 select * from cf_qb_info limit 0,20 2.深度分页:耗时10.236秒 select * from cf_qb_info limit 20000

  • 快速解决mysql深分页问题

    目录 背景 概括 1.limit深分页问题描述 2.sql慢原因分析 聚簇索引和非聚簇索引 常见解决方案 通过子查询优化 标签记录法 方案对比 实战案例 总结 背景 日常需求开发过程中,相信大家对于limit一定不会陌生,但是使用limit时,当偏移量(offset)非常大时,会发现查询效率越来越慢.一开始limit 2000时,可能200ms,就能查询出需要的到数据,但是当limit 4000 offset 100000时,会发现它的查询效率已经需要1S左右,那要是更大的时候呢,只会越来越慢.

  • MySQL调优之SQL查询深度分页问题

    目录 一.问题引入 二.MySQL中的limit用法 三.深度分页优化策略 方法一:用主键id或者唯一索引优化 方法二:利用索引覆盖优化 方法三:基于索引再排序 方法四:基于索引使用prepare 方法五:利用"子查询+索引"快速定位数据 方法六:利用复合索引进行优化 一.问题引入 例如当前存在一张表test_user,然后往这个表里面插入3百万的数据: CREATE TABLE `test_user` ( `id` int(11) NOT NULL AUTO_INCREMENT CO

  • Mysql中分页查询的两个解决方法比较

    mysql中分页查询有两种方式, 一种是使用COUNT(*)的方式,具体代码如下 复制代码 代码如下: SELECT COUNT(*) FROM foo WHERE b = 1; SELECT a FROM foo WHERE b = 1 LIMIT 100,10; 另外一种是使用SQL_CALC_FOUND_ROWS 复制代码 代码如下: SELECT SQL_CALC_FOUND_ROWS a FROM foo WHERE b = 1 LIMIT 100, 10; SELECT FOUND_

  • 完美解决MybatisPlus插件分页查询不起作用总是查询全部数据问题

    问题描述: 在使用mybatisplus插件进行分页查询时分页参数不起作用,总是查出来全部数据. 原因分析: 查看打印的sql日志发现sql后面并没有limit条件,怀疑是缺少配置. 解决方案: 查阅资料通过添加配置类MybatisPlusConfig解决问题: @Configuration public class MybatisPlusConfig { @Bean public PaginationInterceptor paginationInterceptor(){ return new

  • 解决mybatis plus 分页查询有条数,total和pages都是零的问题

    一. 问题还原 1. Controller代码部分 Page<FixedAssetsEntity> pageForPlus = getPage(); Page<FixedAssetsEntity> fixedAssetsEntityPage = fixedAssetsService.selectPage(pageForPlus); 2.spring-mybatis.xml中的sqlSessionFactory配置 <bean id="sqlSessionFactor

  • 解决Mybatis-Plus操作分页后数据失效问题

    业务场景 我们知道在使用PageHelper分页插件时,会对执行PageHelper.startPage(pageNum, pageSize);方法后的第一条查询语句进行分页操作.在开发中总会遇到这样的业务情景,在进行分页查询后,需要对获得的列表数据包装成另一种类型,此时需要对新类型的列表进行分页,然而由于PageInfo<T>因为泛型的原因,导致处理后的列表不能加入到该类中. 如,我在数据库分页后查询到的类为PageInfo<User>,此时改类中的list属性为User,在当前

  • MySql深分页问题解决

    目录 1. 问题描述 2. 问题分析 3. 验证测试 3.1 创建两个表 3.2 创建两个函数 3.3 编写存储过程 3.4 编写存储过程 3.5 创建索引 3.6 验证测试 4. 解决方案 4.1 使用索引覆盖+子查询优化 4.2 起始位置重定义 4.3 降级策略 5. 梳理总结 1. 问题描述 日常开发中经常会涉及到数据查询分页的问题,一般情况下都是根据前端传入页数与页码通过mysql的limit方式实现分页,对于数据量较小的情况下没有问题,但是如果数据量很大,深分页可能导致查询效率低下,接

随机推荐