暗茧1. MyBatis-Plus分页机制原理解析
MyBatis-Plus作为MyBatis的增强工具，其分页功能通过PaginationInnerInterceptor拦截器实现。当执行分页查询时，拦截器会动态修改原始SQL语句，添加数据库特定的分页语法。以MySQL为例，SELECT * FROM user会被改写为SELECT * FROM user LIMIT 0,10。
核心处理流程分为三个阶段：
- SQL解析阶段：通过JSqlParser解析原始SQL，识别查询主体
- 计数查询生成：自动生成
SELECT COUNT(1)语句获取总数 - 分页SQL重构：根据Page对象参数拼接LIMIT/OFFSET子句
java复制// 典型分页查询示例
Page<User> page = new Page<>(1, 10); // 当前页,每页条数
userMapper.selectPage(page, Wrappers.<User>query().eq("status", 1));
关键点：分页拦截器默认会对所有返回类型为IPage的查询生效，无需手动声明分页SQL
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 性能瓶颈深度诊断
2.1 计数查询性能问题
当表数据量超过百万时，COUNT(1)操作可能成为性能瓶颈。测试数据显示：
| 数据量 | 基础COUNT(1)耗时 | 优化方案耗时 |
|---|---|---|
| 100万 | 1200ms | 300ms |
| 500万 | 5800ms | 900ms |
| 1000万 | 超时(>10s) | 1500ms |
问题根源在于：
- 全表扫描统计行数
- 未利用索引覆盖
- 分布式环境下的聚合计算开销
2.2 分页偏移量效率衰减
深度分页时（如pageNum>10000），OFFSET机制导致性能急剧下降。这是因为数据库需要：
- 扫描并丢弃前N条记录
- 返回后续M条记录
sql复制/* 低效的深度分页 */
SELECT * FROM large_table LIMIT 1000000, 20
3. 六大核心优化方案
3.1 自定义计数查询优化
覆盖默认的SELECT COUNT(1)行为：
java复制@Select("SELECT COUNT(1) FROM user WHERE status=1 USE INDEX(idx_status)")
Long customCount();
优化要点：
- 指定使用特定索引
- 添加查询条件缩小统计范围
- 复杂场景可使用近似统计（如EXPLAIN预估行数）
3.2 游标分页实现
采用"记住上次位置"的方式替代传统分页：
java复制//