RowBounds 是一次性查询全部结果吗？为什么？

RowBounds在多数情况下并非一次性查询全部结果，而是mybatis在结果集中按offset和limit进行内存截取，若数据库未优化则可能返回全部数据，造成“假分页”；其与数据库原生分页（如LIMIT/OFFSET）的核心区别在于分页层级——RowBounds为应用层逻辑分页，而原生分页由数据库引擎执行物理分页，显著减少数据传输与资源消耗；适用于小数据量、低并发或老旧系统等场景，但大数据下易引发性能瓶颈；为避免问题，推荐使用PageHelper等分页插件实现sql重写以达成物理分页，或手动编写数据库特定分页语句，并结合索引优化与ResultHandler流式处理提升效率。

RowBounds

在多数情况下，尤其是对于大型数据集，并非一次性查询全部结果。它更像是一种逻辑上的分页指令，MyBatis 会将这个指令传递给 JDBC 驱动，至于驱动和数据库如何执行，则取决于具体的实现和配置。很多时候，如果数据库本身不支持高效的

LIMIT

/

OFFSET

等分页语法，或者驱动没有做特殊优化，那么数据库确实可能将符合条件的所有数据都返回给 JDBC 驱动，再由 MyBatis 在内存中进行截取。这就是为什么在某些场景下，你会觉得它“查询了全部”。

解决方案

理解

RowBounds

的工作机制，关键在于认识到它是一个逻辑分页的概念，而非强制的物理分页。在 MyBatis 中，当你使用

RowBounds

对象（包含

OFFSET

和

LIMIT

）作为方法参数时，MyBatis 会在执行 SQL 查询后，尝试在结果集层面应用这个偏移量和限制。

具体来说，MyBatis 拿到数据库返回的

ResultSet

后，会根据

RowBounds

的

OFFSET

跳过指定数量的记录，然后从

offset + 1

的位置开始读取

LIMIT

数量的记录。这意味着，如果数据库没有在底层对查询进行优化（比如通过

LIMIT

或

TOP

关键字），那么数据库实际上是执行了完整的查询，并返回了所有匹配的行，只是 MyBatis 在处理这些行时只取了你指定的那一部分。

这在小数据量时通常不是问题，但在面对百万级甚至千万级数据时，如果数据库将所有结果都传输到应用服务器，再由 MyBatis 在内存中过滤，那么网络传输、内存占用和CPU消耗都会成为严重的性能瓶颈。这也就是我们常说的“假分页”或“内存分页”。

RowBounds

与数据库原生分页有什么区别？

这真的是个核心问题，也是我个人在项目中经常需要向团队解释的。简单来说，

RowBounds

是一种应用层或驱动层的“分页”处理，而数据库原生分页（如

LIMIT

、

OFFSET

、

TOP

、

ROW_NUMBER()

）则是数据库引擎层面的优化。

数据库原生分页，比如 mysql 的

LIMIT offset, limit

，或者 SQL Server 2012+ 的

OFFSET N ROWS FETCH NEXT M ROWS ONLY

，它们是在数据库内部就完成了结果集的裁剪。这意味着数据库在执行查询时，只会扫描并返回你实际需要的那部分数据，而不是全部数据。这大大减少了数据传输量、数据库的I/O操作以及内存消耗。对于大型表和高并发场景，这种效率差异是巨大的。

而

RowBounds

，如前所述，它通常不修改原始的 SQL 语句。MyBatis 只是在接收到数据库返回的完整结果集后，在应用程序内存中进行跳过和截取。你可以想象一下，如果一个查询本来会返回100万条数据，而你只想要其中的第100到第110条，使用

RowBounds

可能会导致这100万条数据先被数据库查询出来，再通过网络传输到应用服务器，最后才在应用服务器的内存中被筛选掉999990条。这显然效率低下。

什么时候使用

RowBounds

是合适的选择？

虽然

RowBounds

有其局限性，但并非一无是处。在某些特定场景下，它仍然是可用甚至合适的选择：

首先，针对数据量极小的查询结果。如果你的查询结果集通常只有几十、几百条，甚至几千条记录，那么

RowBounds

带来的性能开销几乎可以忽略不计。这种情况下，为了简化代码或者避免引入额外的分页插件，直接使用

RowBounds

是完全可以接受的。

其次，当你需要对一个已经加载到内存中的集合进行分页时。虽然这不是

RowBounds

的主要设计目的，但如果你已经通过其他方式获取了一个完整的数据列表，并希望对其进行内存中的分页展示，

RowBounds

的逻辑可以启发你实现类似的功能。

再者，在一些特殊或老旧的数据库环境中，如果数据库本身对标准的

LIMIT

/

OFFSET

语法支持不佳，或者你需要一个非常通用的 Mapper 接口，不希望为每种数据库编写特定的分页 SQL，那么

RowBounds

提供了一种“万金油”式的分页方案。虽然效率不高，但至少能实现功能。

最后，对于一些内部工具或报表系统，如果对响应时间的要求不高，或者查询的并发量很低，那么

RowBounds

的简单性可能比其潜在的性能问题更具吸引力。毕竟，不是所有的查询都需要极致的性能优化。

如何避免

RowBounds

可能带来的性能问题？

既然我们知道

RowBounds

在大数据量下可能导致性能问题，那么如何规避它就显得尤为重要。

最直接且推荐的方式是使用MyBatis 分页插件。目前社区中最流行、功能最强大的就是

PageHelper

。这类插件的原理是在 MyBatis 执行 SQL 之前，通过拦截器机制对原始 SQL 进行重写，根据不同的数据库类型（MySQL、oracle、SQL Server等）自动添加对应的分页语法（如

LIMIT

、

ROW_NUMBER()

）。这样，分页操作就从应用层下沉到了数据库层，实现了真正的物理分页，极大地提升了查询效率。引入插件通常只需要简单的配置，无需手动修改大量 SQL。

另一种方法是手动编写带有数据库原生分页语法的 SQL。这意味着你需要在 MyBatis 的 xml Mapper 文件中，根据目标数据库的类型，直接写出

LIMIT

、

OFFSET

或

ROW_NUMBER()

等关键字。这要求开发者对不同数据库的分页语法有清晰的了解，并且在多数据库兼容的场景下，可能需要编写多套 SQL 或使用动态 SQL 来适应。虽然这种方式能达到最佳性能，但维护成本相对较高。

此外，优化你的查询本身也很重要。确保你的 SQL 语句使用了合适的索引，避免全表扫描。即使使用了物理分页，如果查询本身效率低下，分页也无法完全解决问题。

最后，如果你真的需要处理超大规模数据集的流式读取，而不是分页，可以考虑 MyBatis 的

ResultHandler

机制。它允许你在处理结果集时逐行进行操作，而不是一次性加载所有结果到内存中，这对于导出大量数据等场景非常有用，但它不是用来做分页的。