在省一级的心理数据总控中心，后台系统中有一张记录全省学生测评明细的数据表，数据量往往达到数百万级别。
在日常使用中，如果管理员在页面底部输入页码并跳转到靠后的页数（例如第 50000 页），可能会引发系统的性能问题。这类查询在执行时，不仅耗时可能长达数秒甚至几十秒，还会导致 MySQL 数据库的 CPU 占用率显著上升，进而影响同一数据库实例上的其他查询操作。
这就是在海量数据报表场景中常见的深分页（Deep Paging）问题。本文将分析 LIMIT 语句在深分页时的性能瓶颈，并探讨如何通过 SQL 优化来解决这一问题。
在执行类似 SELECT * FROM psyrecords ORDER BY createtime DESC LIMIT 1000000, 20 的语句时，很多人误以为数据库会直接定位到第 100 万行并取出随后的 20 行数据。
实际上，在 InnoDB 存储引擎中，面对这种深分页查询，数据库必须从第 1 行开始扫描。它会读取前面的 100 万行记录，然后再读取所需的 20 行，最后将前面的 100 万行记录丢弃，仅返回最后 20 行。由于 SELECT * 会提取整行数据，这种大范围的扫描和数据搬运不仅产生大量的磁盘 I/O 操作，还会带来较大的 CPU 开销。
为了减少大范围扫描完整数据行带来的开销，橙星云技术团队在实践中通常会采用延迟关联的技术方案。
具体做法是，先让 MySQL 在辅助索引（例如基于 create_time 的索引）上进行分页操作。在这个阶段，我们不查询完整的业务字段，只提取主键 ID。
“`sql
— 优化后的延迟关联 SQL
SELECT t1.* FROM psy_records t1
JOIN (
— 在辅助索引上进行查询，只获取这 20 条记录的主键 ID
SELECT id FROM psyrecords ORDER BY createtime DESC LIMIT 1000000, 20
) t2
ON t1.id = t2.id;
“`
在内部的子查询中，因为只涉及 id 和 create_time，MySQL 会利用覆盖索引特性，直接在较小的索引树上完成大量的数据遍历，而无需回表读取完整的行数据。获取到这 20 个目标 ID 后，再通过主键关联主表获取详细数据。这种方式将查询耗时控制在了合理范围内。
对于移动端下拉刷新或瀑布流加载的场景，我们可以采用更高效的游标翻页方案，以避免大偏移量带来的扫描成本。
在游标翻页中，当客户端请求数据时，不再传递传统的页码，而是将上一页最后一条记录的主键 ID 作为游标传递给后端。
后端接收到游标后，可以使用如下 SQL 进行查询：
“`sql
— 使用游标进行精确过滤
SELECT * FROM psy_records
WHERE id < 999980
ORDER BY id DESC LIMIT 20;
“`
由于指定了 id < 999980，MySQL 可以利用主键索引直接定位到该位置，随后顺着 B+ 树向后读取 20 条记录即可。这种查询方式避免了扫描和丢弃前面数据的过程，无论数据偏移量有多大，查询时间都相对稳定，时间复杂度接近常量级别。
在处理 B 端应用的海量数据分页时，传统的 LIMIT offset 语法在面临大偏移量时存在明显的性能瓶颈。通过引入延迟关联以利用覆盖索引，或者在特定场景下采用游标翻页，开发人员可以有效降低数据库的 CPU 和 I/O 负担，确保海量心理档案数据在翻页时的查询效率与系统稳定性。