MyBatisPlus 分页查询大量 TTS 生成记录，如何真正提升响应速度？
在当前 AI 音频内容爆发式增长的背景下，文本转语音（TTS）系统早已不再是实验室里的“玩具”，而是支撑智能客服、有声书平台、虚拟主播等高并发业务的核心组件。以 GLM-TTS 这类支持零样本克隆与音素级控制的开源项目为例，其推理能力强大，但随之而来的是后台任务数据量的急剧膨胀——成千上万条语音生成记录堆积在数据库中，若不加以优化，简单的“查看历史任务”操作都可能让页面卡顿数秒，甚至拖垮整个服务。
面对这种典型的大数据量读取场景，很多开发者的第一反应是：“加索引”、“换 SSD”、“上缓存”。这些当然有用，但往往忽略了最根本的一点：我们真的需要一次性加载全部数据吗？
答案显然是否定的。用户浏览网页时，从来不会一口气看完一万条记录。他们只需要一页一页地看，每页十几到几十条就够了。问题的关键不是“怎么快”，而是“别多拿”。
这正是分页的意义所在，而 MyBatisPlus 的分页机制，则将这一理念做到了极致简化和高效执行。
想象一下这个场景：你的运营同事打开后台管理系统，想查一条三天前生成的方言音频任务，文件名大概是output_789.wav。他点击“任务列表”，结果浏览器转圈了五秒才出来一个表格，翻到第三页还没找到目标。这时候，他不会关心模型精度有多高，只会抱怨：“系统太慢了。”
其实，罪魁祸首很可能就是那一句看似无害的 SQL：
SELECT * FROM tts_task ORDER BY create_time DESC;当这张表的数据量突破 5 万条后，这条语句不仅会触发全表扫描，还会把几十 MB 的数据从数据库拉到应用服务器，再通过网络传给前端。内存、IO、连接池，层层承压。更糟糕的是，如果多个用户同时访问，数据库连接池瞬间被打满，连锁反应随之而来。
解决办法并不复杂：用物理分页代替全量查询。
MyBatisPlus 提供的PaginationInnerInterceptor正是为此而生。它不是一个花哨的功能扩展，而是一种工程上的“克制”——告诉系统：“你只该拿当前需要的那部分数据。”
它的实现原理其实很清晰：当你传入一个Page<T>对象时，框架会自动拦截原始查询，并生成两条 SQL：
- 主查询：带
LIMIT和OFFSET的分页数据； - 总数查询：
SELECT COUNT(*)获取总条数。
比如调用：
Page<TtsTask> page = new Page<>(2, 20); ttsTaskService.page(page, wrapper);底层实际执行的是：
-- 查询第2页，每页20条 SELECT * FROM tts_task ORDER BY create_time DESC LIMIT 20 OFFSET 20; -- 统计总数 SELECT COUNT(*) FROM tts_task;虽然多了一次查询，但传输的数据量从“全部”变成了“一页”，整体响应时间通常能下降 80% 以上。尤其对于 Web 场景来说，用户感知的“快”，本质上就是“快速首屏渲染”，而这正是分页带来的最大收益。
不过，这里有个细节值得注意：分页插件必须正确配置才能生效。很多人引入了依赖，写了page()方法，却发现 SQL 没有被重写——原因往往是忘了注册拦截器。
正确的配置方式如下：
@Configuration @MapperScan("com.example.mapper") public class MyBatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }只要加上这段代码，所有符合规范的page()调用都会自动启用物理分页。无需修改 XML，无需手动拼接LIMIT，甚至连数据库类型都能自动识别（如 Oracle 会生成ROWNUM逻辑）。这就是 MyBatisPlus 的价值：把重复劳动标准化，让开发者专注于业务本身。
回到 TTS 系统的实际场景，我们可以这样封装服务层逻辑：
@Service public class TtsTaskService extends ServiceImpl<TtsTaskMapper, TtsTask> { public IPage<TtsTask> getTasksByPage(int pageNum, int pageSize) { Page<TtsTask> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<TtsTask> wrapper = new LambdaQueryWrapper<>(); wrapper.orderByDesc(TtsTask::getCreateTime); return this.page(page, wrapper); } }控制器只需暴露标准接口：
@RestController @RequestMapping("/api/tts/tasks") public class TtsTaskController { @Autowired private TtsTaskService ttsTaskService; @GetMapping public ResponseEntity<IPage<TtsTask>> getTasks( @RequestParam(defaultValue = "1") int page, @RequestParam(defaultValue = "10") int size) { IPage<TtsTask> result = ttsTaskService.getTasksByPage(page, size); return ResponseEntity.ok(result); } }前后端分离架构下，前端拿到的结果结构清晰：
{ "records": [...], "total": 12345, "size": 10, "current": 1, "pages": 1235 }可以轻松实现“共 12345 条，第 1/1235 页”的展示效果，用户体验大幅提升。
但这还只是起点。真正的挑战在于：当数据量继续增长到百万级时，传统分页也会失效。
你有没有遇到过这种情况：用户点开第 5000 页，系统又开始卡住了？
原因是OFFSET 50000实际上要先扫描前 5 万行数据，即使你只想要后面的 10 条。MySQL 并不会跳过它们，而是逐行判断是否满足条件，最终导致性能急剧下降。这种现象被称为“深度分页陷阱”。
对此，业内有两种主流应对策略：
1. 游标分页（Cursor-based Pagination）
放弃使用OFFSET，改为基于排序字段（如create_time或id）进行范围查询。例如：
// 假设上一页最后一条记录的时间为 2024-03-01 10:00:00 wrapper.lt(TtsTask::getCreateTime, "2024-03-01 10:00:00"); wrapper.orderByDesc(TtsTask::getCreateTime); wrapper.last("LIMIT 20"); // 手动限制数量这种方式效率极高，因为可以直接利用索引快速定位起始位置，避免全表扫描。缺点是无法直接跳转到任意页码，适合“无限滚动”类场景。
2. 关键字段索引 + 缓存组合拳
对于仍需支持传统分页的管理后台，可以在create_time字段建立倒序索引：
ALTER TABLE tts_task ADD INDEX idx_create_time (create_time DESC);配合 Redis 缓存热点页数据（如首页、最近十页），设置 TTL=60 秒，可有效降低数据库压力。实测表明，在日增 2000 条任务的系统中，该策略能使分页接口平均响应时间从 800ms 降至 80ms。
此外，还可以进一步增强查询能力。比如用户想找某个特定输出文件：
wrapper.like(TtsTask::getOutputName, "789");结合分页，实现“搜索+翻页”联动，极大提升可用性。比起让用户导出 CSV 再本地查找，这才是现代系统的应有之义。
值得一提的是，有些团队为了“彻底解决问题”，选择在后台提供“异步导出”功能：用户点击“下载全部记录”，系统生成 CSV 后通过邮件发送。这固然是个好做法，但它解决的是“获取全量数据”的需求，而不是“日常浏览”的体验问题。两者并行不悖，但优先级不同——你应该先确保常规操作流畅，再去考虑极端场景。
说到工程实践，还有一些经验值得分享：
- 每页大小建议控制在 10~50 条之间。超过 50 条，前端渲染变慢；少于 10 条，翻页频繁，体验割裂。
- 不要盲目相信 COUNT(*) 性能。在大表上执行
COUNT(*)本身也可能很慢，尤其是没有主键索引或使用 MyISAM 引擎的老系统。此时可考虑用近似值（如 INFORMATION_SCHEMA.TABLES 中的table_rows）做估算。 - 警惕 N+1 查询问题。如果你的
TtsTask关联了其他实体（如用户信息、项目分类），记得开启 MyBatisPlus 的@TableField(exist = false)或使用 DTO 显式投影，避免关联查询爆炸。
最后回到本质：为什么我们要关注分页？
因为在真实的生产环境中，系统的瓶颈往往不在算法多先进，而在基础设施能否扛住日常流量。一个响应迅速、稳定可靠的后台系统，远比一个“理论上很强”但经常卡顿的服务更能赢得信任。
MyBatisPlus 的分页功能，看似只是一个小小的工具特性，实则是构建可伸缩系统的重要一环。它提醒我们：优秀的架构，不在于堆了多少新技术，而在于是否能在恰当的时机，拿出恰到好处的解决方案。
未来，随着任务量持续增长，也许你会引入 Elasticsearch 实现全文检索，或者用 Kafka 解耦任务状态更新。但在那一天到来之前，请先确保最基本的分页查询是高效的——因为它可能是影响用户体验最直接、最普遍的那个环节。
而这一切，或许只需要几行配置和一次page()调用就能实现。
