JAVA分页实现：五种高效下一页功能代码详解

在Web应用开发中，分页是处理大量数据展示的核心功能之一。一个高效的“下一页”功能不仅能提升用户体验，还能显著降低服务器和数据库的压力。本文将深入探讨五种在JAVA中实现高效分页功能的方法，从基础到进阶，详细解析其原理与代码实现，帮助开发者根据不同场景选择最佳方案。

一、基于LIMIT与OFFSET的传统数据库分页

这是最常见和直接的分页实现方式，尤其适用于MySQL、PostgreSQL等支持LIMIT子句的数据库。其核心思想是通过计算偏移量来获取指定范围的数据。

实现原理与代码

通过传入当前页码（pageNum）和每页大小（pageSize），计算出数据库查询的起始位置（offset）。SQL模板通常为：SELECT * FROM table_name LIMIT ? OFFSET ?。对应的JAVA计算代码如下：

public Page<User> getUsersByPage(int pageNum, int pageSize) {
    int offset = (pageNum - 1) * pageSize; // 计算偏移量
    String sql = "SELECT * FROM user ORDER BY id LIMIT ? OFFSET ?";
    // 使用JdbcTemplate、MyBatis等执行查询，获取当页数据列表 list
    List<User> list = jdbcTemplate.query(sql, new Object[]{pageSize, offset}, ...);
    // 查询总记录数 total
    int total = jdbcTemplate.queryForObject("SELECT COUNT(*) FROM user", Integer.class);
    return new Page<>(list, pageNum, pageSize, total);
}

优点：实现简单，通用性强。缺点：在偏移量非常大时（如OFFSET 10000），数据库仍需扫描并跳过大量行，性能会明显下降。

二、基于游标（Cursor）或“最后ID”的分页

也称为“键集分页”，是解决深度分页性能问题的经典方案。它不依赖页码，而是利用已查询结果的最后一个记录的ID（或时间戳）作为“游标”来获取下一页。

实现原理与代码

客户端请求时携带上一页最后一条记录的ID（例如lastId）。下一页的查询条件即为ID大于这个lastId。这种方式保证了查询始终能利用索引高效定位。

public List<User> getUsersByCursor(Long lastId, int pageSize) {
    String sql;
    if (lastId == null || lastId == 0) {
        // 第一页
        sql = "SELECT * FROM user ORDER BY id ASC LIMIT ?";
        return jdbcTemplate.query(sql, new Object[]{pageSize}, ...);
    } else {
        // 获取“下一页”
        sql = "SELECT * FROM user WHERE id > ? ORDER BY id ASC LIMIT ?";
        return jdbcTemplate.query(sql, new Object[]{lastId, pageSize}, ...);
    }
}

优点：性能极高，不受数据偏移量影响，特别适合无限滚动加载。缺点：无法直接跳转到任意页码，需要连续遍历。

三、使用MyBatis-PageHelper插件简化开发

对于使用MyBatis框架的项目，PageHelper是一个极受欢迎的分页插件。它通过拦截器机制，在运行时自动将查询语句转换为分页查询，极大简化了开发工作。

实现原理与代码

只需在查询方法前调用PageHelper.startPage(pageNum, pageSize)，其后的第一个MyBatis查询方法就会自动进行物理分页。

@GetMapping("/users")
public PageInfo<User> getUsers(@RequestParam int pageNum, @RequestParam int pageSize) {
    // 紧跟在startPage方法后的第一个SELECT查询会被分页
    PageHelper.startPage(pageNum, pageSize);
    List<User> userList = userMapper.selectAllUsers(); // 原样编写查询方法
    // 用PageInfo包装结果，包含详细分页信息
    PageInfo<User> pageInfo = new PageInfo<>(userList);
    return pageInfo;
}

优点：非侵入式，使用简单，无需修改原有SQL，支持多种数据库。缺点：属于框架封装，底层仍依赖数据库的分页语法，深度分页问题仍需注意。

四、基于Spring Data JPA的Repository分页

在Spring Boot生态中，Spring Data JPA提供了声明式的、高度抽象的分页支持。只需在Repository接口中定义方法并接收Pageable参数，即可轻松获得分页结果。

实现原理与代码

JPA会根据Pageable对象自动生成带有分页的SQL，并执行一次额外的计数查询来获取总记录数。

// 1. Repository接口定义
public interface UserRepository extends JpaRepository<User, Long> {
    Page<User> findAllByOrderByIdAsc(Pageable pageable);
}

// 2. Service或Controller中调用
@GetMapping("/users")
public Page<User> getUsers(Pageable pageable) { // 可直接接收?page=0&size=10&sort=id,asc参数
    return userRepository.findAllByOrderByIdAsc(pageable);
}

优点：标准化，与Spring生态无缝集成，功能丰富（支持排序等）。缺点：深度分页性能问题依然存在，且对复杂自定义SQL的分页支持需要额外编写。

五、应用层缓存分页（优化高频访问）

对于数据变化不频繁但访问频率极高的查询，可以将全部或部分数据缓存在应用层（如Redis），在内存中完成分页计算，从而彻底避免数据库的重复压力。

实现原理与代码

首次或定时从数据库加载数据到缓存列表。当分页请求到达时，直接从缓存列表中执行子列表截取。

@Service
public class CachedUserService {
    @Autowired
    private RedisTemplate<String, Object> redisTemplate;
    private static final String CACHE_KEY = "ALL_USERS";

    public List<User> getUsersByPageFromCache(int pageNum, int pageSize) {
        List<User> allUsers = (List<User>) redisTemplate.opsForValue().get(CACHE_KEY);
        if (allUsers == null) {
            allUsers = loadAllUsersToCache(); // 从DB加载并存入缓存
        }
        // 在内存中计算分页
        int fromIndex = (pageNum - 1) * pageSize;
        if (fromIndex >= allUsers.size()) {
            return Collections.emptyList();
        }
        int toIndex = Math.min(fromIndex + pageSize, allUsers.size());
        return allUsers.subList(fromIndex, toIndex);
    }
}

优点：分页响应速度极快，极大减轻数据库负担。缺点：数据实时性差，占用内存大，只适用于特定场景。

总结与选择建议

实现JAVA高效的“下一页”功能，没有一种放之四海而皆准的方案。开发者需要根据具体业务场景进行权衡：

追求简单通用：可选择传统LIMIT分页或MyBatis-PageHelper。
应对海量数据与深度分页：游标分页是最佳选择，尤其适合APP信息流。
基于Spring Boot的快速开发：Spring Data JPA的分页抽象是最优雅的方式。
优化极限性能与高频访问：考虑使用应用层缓存分页作为补充方案。