Java中Stream的limit和skip不适合数据库级高性能分页，因其需顺序遍历前n个元素，时间复杂度O(n)；高性能分页应依赖数据库原生分页（如LIMIT OFFSET），Stream仅适用于小数据集或已分页后的结果处理。
Java 中 Stream 的 limit 和 skip 方法本身**不适合直接用于数据库级的高性能分页**，因为它们是针对内存中已存在的数据流做截取，会强制加载并遍历前面所有元素，导致时间复杂度为 O(n)，在大数据量时性能急剧下降。真正高性能分页必须依赖数据库的原生分页能力（如 MySQL 的 LIMIT offset, size 或 PostgreSQL 的 OFFSET ... LIMIT），Stream 只应在**内存集合小、或已按需查出目标页数据后**才用作轻量处理。
为什么 limit + skip 不适合大数据分页
skip(n) 必须跳过前 n 个元素，而 Stream 是惰性求值但不可回溯的——它只能顺序消费。即使你只想要第 10001~10010 条，Stream 仍要从头遍历前 10000 个元素（哪怕这些元素最终被丢弃）。这在百万级列表中会造成明显延迟和 GC 压力。
- 假设集合有 100 万条数据，查第 1000 页（每页 10 条）：需
skip(9990)→ 遍历 9990 次，再取 10 条 - 没有索引加速，无法“随机访问”，本质是线性扫描
- 中间操作不改变源集合，但
skip仍要消耗 CPU 和时间
正确使用 limit 和 skip 的场景
适用于：本地小集合分页预览、测试模拟、缓存后的小数据集加工，或与数据库分页配合做二次处理（如字段转换、过滤）。
- 对已查出的某一页数据（例如 DAO 层已用 SQL 分页查出 20 条）用 Stream 做映射或过滤：
list.stream().map(...).filter(...).collect(...) - 单元测试中生成测试数据并取前 N 条：
Stream.iterate(1, i -> i + 1).limit(1000).skip(50).collect(Collectors.toList()) - 配置项或枚举列表等固定小数据，按需切片展示
替代方案：用数据库分页 + Stream 后处理
高性能分页的核心是让数据库承担偏移和限制，Java 层只处理结果。以 MyBatis Plus 为例：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 用
Page<User> page = new Page<>(current, size);构造分页参数 - 调用
userMapper.selectPage(page, queryWrapper)，底层自动生成LIMIT ? OFFSET ? - 拿到
page.getRecords()（即本页 10 条）后，再用 Stream 做业务逻辑：page.getRecords().stream().map(User::toDto).collect(Collectors.toList())
这样 skip 和 limit 的代价由数据库引擎优化（利用索引快速定位），Java 层零跳过开销。
如果坚持用 Stream 做内存分页：务必先转成可索引结构
若数据已在内存且无法改用数据库分页（如临时计算结果），应避免反复调用 skip。更高效的做法是：
- 将 Stream 转为
List或数组（一次遍历），再用下标取数：list.subList(fromIndex, Math.min(toIndex, list.size())) - 用 IntStream 索引访问（适合大集合+多次分页）：
IntStream.range(start, Math.min(end, list.size())).mapToObj(list::get).collect(...) - 慎用
StreamSupport.stream(Spliterators.spliterator(...), false)自定义 Spliterator 支持跳过，但实现复杂，一般没必要
本质上，这是用空间换时间：用 O(1) 下标访问替代 O(n) skip 遍历。
