Spring Data JPA分页优化：用Slice替代Page，告别count查询

做后端的人应该都有过这种经历：一个接口平时跑得还行，一到列表页就发烫，查慢SQL日志，发现真正拖后腿的不是那几条业务查询，而是Spring Data JPA顺手帮你执行的那条count。我之前优化一个用户文章列表接口，业务数据量并不大，结果count查询稳定在100ms以上，报表接口更是直接超时。后来把返回类型从Page换成Slice，接口整体响应时间降了一个数量级。从那以后，Slice就成了我处理列表和滚动加载的首选。这篇就把Spring Data里Slice怎么用、和Page有什么本质区别、在真实项目里怎么落地、有哪些坑，一次性讲清楚。适合用Spring Boot加Spring Data JPA做后端接口的同学，也适合想把列表接口从“页码分页”改成“加载更多/无限滚动”的人。

1. 为什么说Slice才是分页的正确打开方式

1.1 Page背后藏着一次多余的count查询

先说最常见的分页写法。平时我们定义一个Repository，大概率是这样：

public interface ArticleRepository extends JpaRepository<Article, Long> { Page<Article> findByUserId(Long userId, Pageable pageable); }

Service里调用：

PageRequest pageable = PageRequest.of(1, 10, Sort.by(Sort.Direction.DESC, "id")); Page<Article> page = articleRepository.findByUserId(userId, pageable);

这段代码用起来确实爽，但这个简单写法的背后，Spring Data JPA会生成两条SQL。先执行count，再执行limit：

select count(1) from article where user_id = ?; select * from article where user_id = ? order by id desc limit 10 offset 10;

问题就出在这条count上。大家总觉得count是“顺便查一下”，可它一点都不便宜。当where条件只有user_id这种简单等值匹配时，count还能走普通索引，但InnoDB的count本质上还是要扫过匹配的索引记录，数据量大了照样吃力。更怕的是业务查询里带like模糊匹配、多表join、or条件，这时候count查询经常要全表扫描或者产生临时表，比真正取数据的limit查询贵出好几个量级。

我遇到过很多“分页慢”的案例，最后定位下来几乎都不是limit慢，而是count慢。前端只需要第一页的10条数据，数据库却要为了一个总数把整张表扫一遍，这个账怎么算都不划算。

1.2 Slice的思路：不数总数，多查一条预判下一页

Slice的翻译是“切片”，在Spring Data里，它代表“从数据库查询结果中切出来的一个小切片”。Slice的语义很明确：我不知道总共有多少片，也不承诺告诉你总数，我只负责给你当前这批数据，顺便告诉你后边还有没有下一个切片。

那Slice是怎么知道还有没有下一页的呢？这是它设计里最巧妙的地方：查询的时候按size加1条去取数据。比如你要10条，它实际会取11条。如果第11条存在，说明后面还有数据，这时hasNext就为true；如果只取到10条甚至更少，说明没有下一页了。

底层逻辑大致是这样一段伪代码：

List<Article> raw = query("... limit ? offset ?", pageSize + 1, offset); boolean hasNext = raw.size() > pageSize; List<Article> content = hasNext ? raw.subList(0, pageSize) : raw; return new SliceImpl<>(content, pageable, hasNext);

一条SQL就搞定了“有没有下一页”的判断，不需要额外count。对比Page的两条SQL，Slice在每次分页查询上都少掉了一整个count开销。这也是它在性能上的核心优势。

另外要注意，因为底层用了size加1的技巧，所以Slice返回后的实际元素个数存在一种特殊情况：如果当前页之前的数据超过size，底层会多取一条，但返回给你的content仍然会截断成size条。也就是说，Slice.getSize()返回的是你请求的每页条数，而getNumberOfElements()返回的是当前页真实内容条数。最后一页不足size时，这两个值一定不相等，这是判断“是否到末尾”的另一个辅助指标。

1.3 什么场景用Page，什么场景用Slice

不是所有分页都必须换成Slice，二者面向的场景完全不同。

我的个人经验是：接到一个接口，先问前端这个列表到底需不需要展示“共多少条”或者总页数。如果只是无限滚动，Slice就是天然的选择。不要因为“多一个总数”看起来方便，就让数据库每次分页都白跑一条大SQL。另外还要记住，Page接口本身就继承自Slice，所以Page能拿到Slice的所有能力，它多出来的只是总数和总页数两个信息，代价就是那次count查询。用不用，完全取决于业务上这两个信息是否真的需要。

2. 深入Slice与Page的接口差异

2.1 接口继承关系与核心方法

先理一下Spring Data Commons里这几个接口的实际关系。Slice是顶层接口，它继承了Streamable，表示一个可以被遍历的数据集合。Chunk是一个抽象类，实现了Slice接口，里面保存了内容列表、可用的Pageable、是否还有下一个切片等核心状态。SliceImpl和PageImpl都继承自Chunk，其中Page接口又继承了Slice接口，在Slice基础上增加了totalElements和totalPages两个统计字段。

Slice接口本身定义的方法并不多，但每个都值得弄清楚：

public interface Slice<T> extends Streamable<T> { int getNumber(); // 当前是第几页，页码从0开始 int getSize(); // 每页请求的条数 int getNumberOfElements(); // 当前页实际返回的条数 List<T> getContent(); // 当前页数据 boolean hasContent(); // 是否有数据 Sort getSort(); // 当前排序规则 boolean isFirst(); // 是否是第一页 boolean isLast(); // 是否最后一页 boolean hasNext(); // 是否有下一页 boolean hasPrevious(); // 是否有上一页 Pageable nextPageable(); // 获取下一页的Pageable Pageable previousPageable(); // 获取上一页的Pageable <S> Slice<S> map(Function<? super T, ? extends S> converter); }

Page接口在Slice基础上增加的方法只有两个：

long getTotalElements(); // 总记录数 int getTotalPages(); // 总页数

这里有一个容易理解错的地方：Slice的isLast()不是基于总数计算出来的，而是hasNext()的取反。也就是说，isLast()为true只代表“按当前查询，后面没有更多数据了”，并不是在说这一定是全表最后一页。这个语义差异在数据持续写入的活跃表上尤其明显。

2.2 从Page切成Slice，代码改动到底有多小

很多人担心把Page换成Slice要动一大堆代码，其实远没有想象中复杂。改造前，如果老代码依赖Page的总数信息，通常会写类似这样的逻辑：

Page<Article> page = articleRepository.findByUserId(userId, pageable); int totalPages = page.getTotalPages(); long total = page.getTotalElements(); boolean hasNextPage = page.getNumber() < totalPages - 1; return new PageResult<>(page.getContent(), total, hasNextPage, page.getNumber());

改成Slice之后，关注点就完全不同了：

Slice<Article> slice = articleRepository.findByUserId(userId, pageable); boolean hasNextPage = slice.hasNext(); return new SliceResult<>(slice.getContent(), slice.hasNext(), slice.getNumber());

真正的迁移工作主要在Service层和Controller层：Repository把返回值类型从Page改成Slice，Service去掉对getTotalElements和getTotalPages的依赖，前端从“渲染总条数/总页数”改成“渲染加载更多按钮/触底自动加载”。如果前端本身就是无限滚动，那后端改动只有几行的事，收益却立竿见影。

2.3 顺便理清slice、splice、slice算子这几个概念

“Slice”这个词在技术圈里太常见了，有时候搜资料会搜到完全不相干的东西。如果你写过JavaScript，一定见过slice和splice两个数组方法。在JS里，arr.slice()是把数组的一段复制出来返回新数组，原数组不变；arr.splice()则会直接修改原数组，用来删除、插入或替换元素。两者拼写很像，但一个是“切片”，一个是“拼接/插拔”，用途完全不同。

大数据领域里经常能听到“slice算子”的说法。在流处理和分布式计算框架中，slice通常指按时间窗口、分区或某种维度把数据集切成小块，方便分布式并行处理。它同样强调的是“从整体中切出一部分”这个动作。

Spring Data里的Slice延续的是同一个语义——你拿到的是整个结果集的一个切片，而不是对整个结果集做统计数据。所以看到Slice这个返回类型，第一反应不应该是“总数是什么”，而应该是“这部分数据是什么，后面还有没有”。

3. 项目实操：从Repository到Service完整落地

3.1 Repository写法与count查询的控制

最简单的方式是这样，把返回类型直接声明为Slice：

public interface ArticleRepository extends JpaRepository<Article, Long> { Slice<Article> findByUserId(Long userId, Pageable pageable); }

关键点在于：当Spring Data JPA看到方法返回类型是Slice时，就不会再额外构建count查询。它只会执行一条带limit/offset的分页查询，并通过size加1的结果集来判断hasNext。而如果方法返回类型是Page，哪怕你只在代码里调用了getContent根本没碰getTotalElements，框架依然会执行count查询，因为总数是Page接口的组成部分。

如果默认派生查询满足不了需求，可以用@Query自定义JPQL：

@Query("select a from Article a where a.userId = :userId and a.status = :status") Slice<Article> findSliceByUserId(@Param("userId") Long userId, @Param("status") Integer status, Pageable pageable);

注意一个细节：返回Slice时不要自己往JPQL里写count，也别在方法上配countQuery属性。那是Page返回类型用来覆盖默认count语句的，Slice根本用不到。写了反而容易被当成普通分页处理，起不到跳过count的效果。

3.2 调用端传参：PageRequest、SliceRequest与Pageable

在调用端，组装分页参数最常见的就是PageRequest：

PageRequest pageable = PageRequest.of(0, 10, Sort.by(Sort.Direction.DESC, "id")); Slice<Article> slice = articleRepository.findByUserId(userId, pageable);

注意PageRequest的页码从0开始。很多刚上手的同学直接传page=1，结果前端传的是“第2页”的时候，后端却当成“第1页”处理，列表错位往往就是这么来的。

如果你的项目用的是Spring Data 3.2及以上版本，新版本里还提供了一个SliceRequest类型，语义上更接近“我要一个切片”，可以少传页码。但做兼容性和老项目迁移，最稳妥的还是继续用PageRequest.of，因为它从Spring Data Commons早期版本一直沿用到今天，不同版本行为一致。

还有一个实践技巧：如果要做真正的游标分页，也就是避免大offset问题，完全可以自己实现Pageable接口，或者更简单的做法是自定义查询条件，把“偏移量”换成“上一页最后一条记录的id”：

@Query("select a from Article a where a.userId = :userId and (:cursorId is null or a.id < :cursorId) order by a.id desc") Slice<Article> findByUserIdWithCursor(@Param("userId") Long userId, @Param("cursorId") Long cursorId, Pageable pageable);

调用时Pageable只需要保留size，比如PageRequest.of(0, 10)。这样每页查询都能直接命中索引范围，彻底避开深分页问题。

3.3 实测对比：一个常见查询的耗时差异

整理一个我在自己测试环境里的对比结果，数据仅供参考，但趋势很有代表性。测试环境是MySQL 8.0，一张article表100万行，user_id上有普通索引，查询条件是user_id固定，order by id desc，取第3页每页10条。

如果业务SQL更复杂，比如带like模糊匹配或者多表join，这个差距会拉得更大。复杂条件下count查询跑到1秒以上很常见，而limit查询通常还是几十毫秒级别。当然，Slice并不能把一条本身写得稀烂的SQL变快，它解决的只是“分页时多跑一次count”这个固定开销。如果分页查询本身扫描行数巨大，那该调索引调索引，该改查询改查询，Slice不是万能药。

4. 无限滚动场景的正确打开方式

4.1 hasNext()与nextPageable()的正确用法

在Service里循环遍历所有分页数据时，Slice的hasNext配合nextPageable相当好用：

Slice<Article> slice = articleRepository.findByUserId(userId, PageRequest.of(0, 20)); while (slice.hasContent()) { handle(slice.getContent()); if (!slice.hasNext()) { break; } slice = articleRepository.findByUserId(userId, slice.nextPageable()); }

nextPageable()会基于当前页码和排序规则，自动生成下一个Pageable对象，省得自己每次手动加page数。但要注意，nextPageable生成的还是offset分页方式，在大数据量深分页场景下依然有性能隐患。

如果是给前端提供API，直接返回Slice也不是不行，但更推荐只把需要的信息返回出去，避免把整个Pageable对象暴露给前端：

@GetMapping("/api/articles") public Map<String, Object> list(@RequestParam Long userId, @RequestParam(defaultValue = "0") int page, @RequestParam(defaultValue = "10") int size) { PageRequest pageable = PageRequest.of(page, size, Sort.by(Sort.Direction.DESC, "id")); Slice<Article> slice = articleRepository.findByUserId(userId, pageable); return Map.of( "content", slice.getContent(), "hasNext", slice.hasNext() ); }

前端只需要知道content和hasNext两个信息，业务逻辑就完整了。

4.2 从“页码分页”改造成“加载更多”的完整模板

前端如果是无限滚动，逻辑大概长这样：

let page = 0; let hasNext = true; async function loadMore() { if (!hasNext) return; const res = await fetch(`/api/articles?userId=1&page=${page}&size=10`); const data = await res.json(); renderList(data.content); hasNext = data.hasNext; page++; }

每次滚动到底部，就判断hasNext，为true则page加1继续请求，为false就显示“没有更多了”。

这里有一个经常被忽略的问题：分页查询的排序字段必须稳定。如果只按create_time排序，而同一秒内有大量新数据插入，翻页时很容易出现数据重复。稳妥的做法是增加一个唯一字段做次级排序，比如create_time desc, id desc，或者直接按id倒序。否则用户下拉几次就会发现列表里出现了之前已经看过的内容，这种体验问题定位起来还挺费劲。

另外，如果列表里会持续新增数据，传统的页码式分页在滚动加载时还是会出问题，新插入的数据会把旧数据往后挤，导致用户明明看过的内容，下一页又出现一遍。这种情况只靠Slice解决不了，需要把页码分页改成游标分页，也就是每次查询带上上一批最后一条记录的id，去查“id小于这个值的下一批”，前面的示例里已经给了对应的Repository写法。Slice在这里可以继续作为返回容器，只是分页参数从页码变成了游标。

5. 踩坑实录：Slice实战失败复盘

5.1 我遇到过的五个典型坑

第一个坑：方法返回类型写成Page，但业务根本不需要总数。这是最常见的性能浪费，虽然没有写死，但count查询就是会在每次查询时默默执行。凡是只需要列表内容的地方，直接用Slice，别让count白白浪费数据库资源。

第二个坑：前端还是老一套分页条。Slice不返回total，前端如果还在渲染“共xx条/第x页”，改造基本没法进行。切Slice之前，必须先跟产品确认交互形态是不是“加载更多”。如果产品坚持要分页条，那还是老老实实用Page，不要为了性能强行改坏产品体验。

第三个坑：页码传给PageRequest.of时从1开始。PageRequest的page参数是0基的，传1代表第二页。很多人接口文档里写的page从1开始，后端代码直接拿它去PageRequest.of，结果首页数据被跳过，最后一页可能拿到空数据。解决办法是在Controller层做一次转换，比如pageParam - 1再传给PageRequest。

第四个坑：排序字段不稳定。Slcie分页依赖排序顺序来判断哪些数据已经展示过。如果排序字段没有唯一性，或者字段值会变化，翻页时就会出现重复或者漏数据。最佳实践是始终加上id作为次级排序字段。

第五个坑：把size调得特别大，比如一次取10000条，想绕过总数问题。这比直接返回List还糟糕，不仅内存占用大，底层SQL的offset扫描成本也会嗖嗖上涨。大数据量场景应该做流式处理或者游标分页，而不是把每页条数拉满。

5.2 排查慢SQL的三种方法

如果你怀疑自己的分页接口被count拖慢了，排查思路其实很清晰。

第一步，打开Spring Data JPA的SQL日志。最直接的配置是：

spring.jpa.show-sql=true spring.jpa.properties.hibernate.format_sql=true logging.level.org.hibernate.SQL=debug logging.level.org.hibernate.type.descriptor.sql.BasicBinder=trace

日志里如果同一个接口请求出现了两条SQL，一条count开头，一条select带limit，那基本可以确认是Page在跑count。

第二步，打开MySQL慢查询日志，或者用performance_schema看看具体SQL耗时。慢查询日志能清楚记录哪条SQL超过了阈值，很多时候就是那条count。

第三步，对主查询执行EXPLAIN：

explain select * from article where user_id = 100 order by id desc limit 10 offset 10;

重点看type和rows字段。如果rows已经很大，说明即使去掉了count，主查询本身还需要优化，比如补复合索引、避免回表、改用游标分页。Slice只解决了count问题，不能解决一个本身就有问题的查询。

6. 最后说一点个人心得

我现在接到一个新接口，第一件事不是写代码，而是先问产品：这个列表需要展示总条数或者总页数吗？如果答案是“不需要”，Repository层就直接返回Slice，Controller只给前端hasNext标志。省掉的那条count查询，对数据库来说就是实打实的压力下降。我上一次把文章列表从Page改成Slice，接口从平均140ms降到了10ms以内，前端只改了十来行代码。如果你正为分页慢发愁，别急着调SQL或者加缓存，先翻一下日志里有没有被忽略的count查询，然后把返回类型换Slice试试。这种改法切口小、风险低，收益往往比想象中明显得多。等列表数据量再上几个量级，再配合游标分页和索引优化，整个分页链路才算真正稳了。