news 2026/4/4 0:24:18

Java分页查询方式总结

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Java分页查询方式总结

文章目录

    • 分页查询核心思路
    • 常见分页实现方式
      • MyBatis
      • MyBatis-Plus

分页查询核心思路

分页的本质是限制查询结果的条数+跳过指定行数,并查询总记录数(用于计算总页数)。核心参数:

  • pageNum:当前页码(从 1 开始)
  • pageSize:每页显示条数
  • 起始行计算:startRow = (pageNum - 1) * pageSize
  • 总页数计算:totalPages = (totalCount + pageSize - 1) / pageSize(向上取整)

常见分页实现方式

MyBatis

1、mapper手动拼SQL

Mapper 接口:

import org.apache.ibatis.annotations.Param; import java.util.List; public interface UserMapper { // 查询分页数据 List<User> selectUserByPage(@Param("startRow") int startRow, @Param("pageSize") int pageSize); // 查询总条数 int selectUserTotalCount(); }

Mapper.xml:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"> <mapper namespace="com.example.mapper.UserMapper"> <!-- 分页查询数据 --> <select id="selectUserByPage" resultType="com.example.entity.User"> SELECT id, name, age FROM user LIMIT #{startRow}, #{pageSize} </select> <!-- 查询总条数 --> <select id="selectUserTotalCount" resultType="int"> SELECT COUNT(*) FROM user </select> </mapper>

2、PageHelper 插件

需要在 pom.xml 中添加 PageHelper 依赖

<dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> <version>1.4.7</version> </dependency>

在调用时添加如下代码

// 开启分页(只对紧接着的第一个查询生效) PageHelper.startPage(pageNum, pageSize);

MyBatis-Plus

1、使用内置分页插件 PaginationInnerInterceptor

Page<Forlan>page=newPage<>(pageNum,pageSize);QueryWrapper<Forlan>queryWrapper=newQueryWrapper<>();queryWrapper.eq("id",id);mapper.selectPage(page,queryWrapper);service.lambdaQuery().page(newPage<>(pageNum,pageSize))

2、基于偏移量的分页(升级写法,自己控制结束)

核心参数:

  1. LIMIT N
    表示“只返回最多 N 条记录”。
    通常用来控制每页显示的数据条数。
  2. OFFSET M
    表示“跳过前 M 条记录”,从第 M+1 条开始取数据。
    用于定位到当前请求的页码起始位置。
    核心:service.query().last("LIMIT " + batchSize + " OFFSET " + offset).list();
finalintbatchSize=1000;List<Forlan>allResults=newArrayList<>();intoffset=0;booleanhasMoreResults=true;while(hasMoreResults){try{List<Forlan>batchResults=service.query().last("LIMIT "+batchSize+" OFFSET "+offset).list();if(batchResults==null||batchResults.isEmpty()){hasMoreResults=false;}else{allResults.addAll(batchResults);offset+=batchResults.size();}}catch(Exceptione){log.info("Error querying batch: ",e);hasMoreResults=false;}}returnallResults;

上面的写法,存在问题:随着 offset 增大,性能下降严重,对大数据量场景不友好,适合深度翻页,比如:

-- 查询第10001页,每页10条数据 SELECT * FROM products ORDER BY id LIMIT 10 OFFSET 100000;

这条SQL的执行逻辑并非直接定位到第100,001条记录。MySQL的实际处理过程是:从存储引擎中读取满足条件的前 100010 (OFFSET + LIMIT) 条记录,在服务层(Server Layer)对这些记录进行排序,抛弃前面的 100000 条记录,返回最终的 10 条记录。

所以,OFFSET 值越大,MySQL需要扫描、加载并最终抛弃的行数就越多,这导致了巨大的I/O和CPU资源浪费,是性能下降的直接原因。

1)延迟关联:优化后的写法

核心思想:先通过覆盖索引快速定位到目标页的主键ID,然后再关联原表获取完整的行数据,从而减少对主表数据的扫描。

LonglastId=0L;finalintbatchSize=1000;List<Forlan>allResults=newArrayList<>();booleanhasMoreResults=true;while(hasMoreResults){try{List<Forlan>batchResults=service.query().gt("id",lastId).last("LIMIT "+batchSize).list();if(batchResults==null||batchResults.isEmpty()){hasMoreResults=false;}else{allResults.addAll(batchResults);lastId=batchResults.get(batchResults.size()-1).getId();}}catch(Exceptione){log.info("Error querying batch: ",e);hasMoreResults=false;}}returnallResults;

存在问题,如果扫描的最小id在几千万,这时候首次查询也是非常耗费时间的,进一步优化的写法如下:

finalintbatchSize=1000;List<Forlan>allResults=newArrayList<>();booleanhasMoreResults=true;Forlanforlan=service.query().select("min(id) id").one();if(forlan==null){returnallResults;}LonglastId=forlan.getId()-1;while(hasMoreResults){try{List<Forlan>batchResults=service.query().gt("id",lastId).last("LIMIT "+batchSize).list();if(batchResults==null||batchResults.isEmpty()){hasMoreResults=false;}else{allResults.addAll(batchResults);lastId=batchResults.get(batchResults.size()-1).getId();}}catch(Exceptione){log.info("Error querying batch: ",e);hasMoreResults=false;}}returnallResults;

2)书签法

是目前性能最优的方案。它摒弃了OFFSET,通过上一页最后一条记录的唯一键值来定位下一页的起始位置,但要求主键或查询条件连续

假设我们按自增id排序,上一页返回的最后一条记录id为100000。不使用OFFSET,而是利用上一页的id进行定位

SELECT * FROM products WHERE id > 100000 ORDER BY id ASC LIMIT 10;

优点:查询性能恒定,不受分页深度影响,速度极快。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/4/3 20:10:37

昆仑通态与东元N310变频器通讯实战之旅

昆仑通态与东元N310变频器通讯实战程序实现昆仑通态触摸屏与东元N310变频器通讯&#xff0c;程序稳定可靠器件&#xff1a;昆仑通态TPC7062KD触摸屏&#xff0c;东元N310变频器&#xff0c;附送接线说明和设置说明 功能&#xff1a;实现频率设定&#xff0c;启停控制&#xff0…

作者头像 李华
网站建设 2026/4/3 13:39:40

vue3 实时通讯 SSE

/*** 原生 EventSource 轻量封装* 自动重连 & 任意事件监听* 支持自定义请求头&#xff08;通过 URL 参数传递 Authorization&#xff09;*/ export default class SSE {private url: string;private es: EventSource | null;private retry: number;private headers?: Rec…

作者头像 李华
网站建设 2026/4/3 16:24:00

震惊!这家酶制剂工厂竟让同行都慌了

震惊&#xff01;这家酶制剂工厂竟让同行都慌了在竞争日益激烈的生物制造领域&#xff0c;一家位于上海的酶制剂生产企业——上海华上翔洋生物&#xff0c;正以其独特的创新模式与卓越的产品力&#xff0c;悄然改变着行业格局&#xff0c;引发了同行的广泛关注与深度思考。引言…

作者头像 李华
网站建设 2026/4/2 14:01:23

如何解决recv被业务阻塞导致的 netlink 消息丢失问题?

先看源码: 现在的问题已经非常清晰了: recv + 业务处理耦合在 select 线程 → netlink buffer 堆积 → 内核丢消息 → VRRP/BFD 状态误判 → 主备抖动/切换(burst(接口 flap / 链路聚合 / 堆叠切换)时必炸 ) 解决办法: 使用队列的方法解决,在 select 线程中:只“快收包…

作者头像 李华
网站建设 2026/3/26 18:17:30

Claude辅助开发:Rust专家利用AI设计新编程语言Rue

为新编程语言命名"Rue"似乎暗示着对项目前景的怀疑&#xff0c;如果将"Rue"理解为"后悔"的话。但是以对Rust和Ruby on Rails贡献闻名的资深软件开发者史蒂夫克拉布尼克表示&#xff0c;这个名称背后有更深层的含义。"Rust这个名字唤起了几种…

作者头像 李华