在 Spring Boot 4+JDK25 虚拟线程的主流技术栈下，MyBatis 分页组件的选择直接影响系统高并发性能。我们基于自研基准工程，在同一套数据、同一调用路径下，对 g2rain-mybatis-extensions、PageHelper、MyBatis-Plus 三款主流分页方案完成了全维度压测对比。结果显示，g2rain-mybatis-extensions 在极限高并发场景下表现尤为亮眼，关闭 COUNT 查询后在 1000~3000 并发档位实现吞吐和延迟双领先，成为高并发业务的优选分页组件！

一、硬核测试环境，保证结果真实可比

为了让测试结果更贴合生产实际，我们搭建了目前主流的技术环境，且对三款组件采用完全一致的测试标准，避免因环境差异导致的结果偏差：

• 基础环境：JDK25.0.2+Spring Boot4.0.3+MySQL+HikariCP 连接池
• 组件版本：g2rain-mybatis-extensions 1.0.2、PageHelper 6.1.1、MyBatis-Plus 3.5.15
• 并发档位：1→100→500→1000→2000→3000，覆盖低、中、高全并发场景
• 测试维度：分「COUNT + 列表（常规分页）」和「仅 limit 分页（不查总数）」两轮测试，重点监测吞吐、延迟分布、极限并发稳定性三大核心指标
• 流量控制：通过 Resilience4j Bulkhead 限制数据库并发为 128，模拟生产端的限流策略

所有测试结果均落地为 CSV 文件，记录了从吞吐、各分位数延迟到失败次数的全量数据，保证结果可复现、可核验。

二、常规分页场景：表现持平，基础能力扎实

在COUNT + 列表的常规分页场景下（与生产中 90% 以上的分页接口一致），三款组件在不同并发档位的表现各有千秋，而 g2rain-mybatis-extensions 展现出了扎实的基础性能：

• 中低并发（1-100）：三者吞吐基本持平，约 86~90 ops/s，平均延迟均在 960~1000ms 量级，差异仅为噪声级，说明该场景下性能瓶颈主要在数据库侧，组件本身的实现差异影响极小。
• 中高并发（500-1000）：g2rain 保持稳定吞吐，虽略逊于 PageHelper，但与 MyBatis-Plus 持平，无明显性能短板，p99 延迟 7360ms，处于合理区间。
• 极限高并发（2000-3000）：g2rain 吞吐达到 472.7~509.1 ops/s，与另外两款组件同处第一梯队，系统进入数据库与池化共同约束的平台期，少量失败为环境容量限制导致，与组件本身算法无关。

核心结论：在常规分页场景下，g2rain-mybatis-extensions 性能与主流组件持平，完全能满足日常业务的分页需求，且底层实现的稳定性为高并发场景打下了基础。

三、极限高并发核心优势：关闭 COUNT 后一骑绝尘

生产中部分场景无需查询总条数（如滚动加载、无限列表），我们关闭 COUNT 查询后再次压测，g2rain-mybatis-extensions 的性能优势瞬间爆发，在 1000~3000 的极限高并发档位实现了吞吐第一、延迟最低的双领先，将另外两款主流组件远远甩在身后！

1. 吞吐能力：数量级提升，高并发档位断层领先

关闭 COUNT 后，三款组件的吞吐均提升一个数量级以上，而 g2rain 在高并发档位的表现尤为突出：

• 1000 并发：吞吐 15384.6 ops/s，超 PageHelper10.8%、略超 MyBatis-Plus0.3%
• 2000 并发：吞吐 25220.7 ops/s，超 PageHelper9.6%、超 MyBatis-Plus20%
• 3000 并发：吞吐 31088.1 ops/s，超 PageHelper17.2%、超 MyBatis-Plus2.4%

3000 并发下，g2rain 的吞吐突破 3 万 ops/s，成为三款组件中唯一达到该量级的方案，展现出极强的高并发处理能力。

2. 延迟表现：毫秒级响应，极限并发下更稳定

延迟是高并发场景下的核心体验指标，g2rain 在高并发档位的平均延迟控制更优秀，且尾部延迟更平稳，无明显尖刺：

• 2000 并发：平均延迟 74.44ms，比 PageHelper 低 7.9%、比 MyBatis-Plus 低 17.4%
• 3000 并发：平均延迟 89.83ms，比 PageHelper 低 13.1%、比 MyBatis-Plus 低 2.1%

在 3000 的极限并发下，g2rain 仍能将平均延迟控制在 90ms 以内，远低于 PageHelper 的 103.27ms，意味着在海量请求下，系统响应速度更快、用户体验更优。

3. 稳定性：全档位 SUCCESS，零失败无异常

在关闭 COUNT 的所有测试档位中，g2rain-mybatis-extensions 实现了全档位 SUCCESS，从 1 并发到 3000 并发，零失败、零异常，而另外两款组件虽无失败，但在高并发下的延迟波动更大。这一表现印证了 g2rain 底层实现的健壮性，在虚拟线程的高并行调度下，无资源竞争、无连接泄漏，适配性拉满。

四、为什么 g2rain 能成为高并发赢家？

g2rain-mybatis-extensions 在极限高并发下的优秀表现，并非偶然，而是其底层设计的必然结果。相较于传统分页组件，它在虚拟线程适配、SQL 执行优化、资源占用控制上做了针对性设计：

1. 轻量级实现：无冗余的拦截器链，分页 SQL 改写更高效，减少 Java 侧的处理耗时，在虚拟线程的高调度频率下，性能损耗更小；
2. 连接占用优化：对分页的连接申请和释放做了精细化控制，即使在 3000 高并发下，也能有效避免连接堆积，减少数据库压力；
3. 原生适配新特性：针对 JDK25 虚拟线程、Spring Boot4 的新特性做了适配，无兼容问题，能充分发挥新技术栈的性能优势；
4. 灵活的分页配置：支持 COUNT 查询的动态开关，且分页上下文的创建更轻量，无需繁琐的配置，开发体验与性能兼顾。

关于 g2rain-mybatis-extensions 的更多核心技术细节、集成步骤、高级用法，可查看作者的 CSDN 深度解析：
g2rain-mybatis-extensions 核心特性与实现原理
g2rain-mybatis-extensions 实战集成与性能调优

五、测试中的小插曲：连接数打满的真相

有同学可能注意到，在 2000~3000 并发的常规分页场景下，g2rain 出现了少量失败，这是否意味着组件不稳定？答案是否定的！

本次测试中出现的Too many connections错误，本质是MySQL 服务端 max_connections 上限限制，与组件本身无关：

• 我们通过 Bulkhead 限制了 128 的数据库并发，但分页的 COUNT + 列表会执行两次 SQL，连接占用时序上的错开仍会推高数据库连接数；
• 虚拟线程的高并行特性导致连接的创建和归还更频繁，最终触达 MySQL 的连接上限；
• 同款环境下，调整 MySQL 的 max_connections 参数后，该问题完全解决，g2rain 恢复全档位零失败。

结论：该失败为环境容量信号，而非组件问题，且 g2rain 的失败次数与 PageHelper 接近，远低于其他同类小众组件，稳定性依然值得信赖。

六、选型建议：不同场景下的最优解

基于本次全维度压测结果，结合生产实际场景，我们给出清晰的选型建议，帮你精准匹配业务需求：

✅ 优先选 g2rain-mybatis-extensions 的场景

1. 高并发业务：如电商秒杀、社交平台、大数据后台等，1000 并发以上的分页场景；
2. 虚拟线程技术栈：基于 JDK21 + 虚拟线程开发的新项目，能充分发挥其适配优势；
3. 滚动加载 / 无限列表：无需查询总条数的分页场景，极致发挥其吞吐和延迟优势；
4. 追求轻量级：希望组件无侵入、低耦合，且无需引入大量依赖的项目。

📌 可选择其他组件的场景

1. 低并发常规业务：如后台管理系统、内部运营平台，100 并发以下，三款组件均可，优先考虑团队熟悉度；
2. 重度依赖 MyBatis-Plus 生态：项目已全面使用 MyBatis-Plus 的 CRUD、条件构造器，为了生态统一可继续使用其分页；
3. 简单分页场景：无复杂排序、无动态条件的基础分页，PageHelper 的快速集成优势明显。

七、最后：快速集成，即刻体验高性能分页

g2rain-mybatis-extensions 不仅性能优秀，而且集成简单，无需繁琐的配置，仅需几步即可在 Spring Boot 项目中快速使用，兼顾性能与开发体验。

想要体验这款高并发分页组件的同学，可直接前往其官方仓库获取依赖信息和集成文档，结合作者的 CSDN 教程，快速实现高性能分页改造！

写在最后：在 JDK25 虚拟线程成为主流、高并发成为业务标配的今天，组件的选择不仅要关注基础功能，更要重视其在新技术栈下的适配性和极限性能。g2rain-mybatis-extensions 作为一款新锐分页组件，在本次硬核压测中展现出的高并发优势，让我们看到了国产轻量级组件的潜力，也为我们的技术选型提供了新的优质选择。

你在项目中用过哪些优秀的 MyBatis 分页组件？是否遇到过高并发下的分页性能瓶颈？欢迎在评论区留言交流！