ThinkPHP分页逻辑：offset+limit在深分页场景下的局限性

先说几个关键判断：ThinkPHP 的深分页变慢，问题不在框架本身，根源是它默认调用了 MySQL 的 LIMIT offset, size 机制。而 MySQL 在执行这类查询时，并不会真的“跳过”前面的行——它会老老实实读出来，排序（如果索引没覆盖），再丢弃。数据量一旦过百万，哪怕 OFFSET 50000 也意味着要扫描五万多行才能返回你真正需要的十几条，CPU 和 I/O 都耗在无用功上了。

为什么 OFFSET 越大查询越卡

说白了，MySQL 在处理 LIMIT offset, size 时，逻辑很简单：“你要第 N 页？那我先把前 N 页的数据全读出来，排好序，再扔掉。”整个过程里，排序和回表是两个最吃力的地方。举个例子，如果表里有 100 万行数据，查第 1000 页（每页 25 条），OFFSET 就是 24975——意味着 MySQL 至少得读取 25000 行，最后只返回 25 条。这就好比你翻一本很厚的书，想直接翻到第 1000 页，但系统非得从第一页开始逐页翻过去，翻完 999 页才停下来。

• 当 SELECT * 配合 ORDER BY created_at，且该字段没有唯一性索引时，还可能触发 Using filesort 甚至 Using temporary，性能进一步恶化。
• 如果 ORDER BY 的字段没索引，或者索引不覆盖全部查询字段，就要回表捞数据，I/O 开销成倍放大。
• 更危险的是，高并发下如果多个深分页请求同时堆积，数据库连接池被拖垮是迟早的事。

在 ThinkPHP 里怎么绕开 paginate() 的 offset 陷阱

最直接的方案就一条：不再依赖 paginate()，而是用 Db::name() 或模型的链式查询手动拼游标逻辑。核心思想很简单——用上一页最后一条记录的排序字段值作为 WHERE 条件，不再通过页码定位。

• 前提条件：排序字段必须唯一、非空、有索引。最推荐的就是主键 id，或者带索引的 created_at。
• 首次请求不带游标：直接 ->where('id', '>', 0) 或者省略 WHERE 条件。
• 后续请求传 cursor=12345（上一页最后一条记录的 id），查询条件改为 ->where('id', '>', 12345)。
• 排序方向要统一：升序就始终 ORDER BY id ASC，降序就始终 ORDER BY id DESC，绝对不能混用。
• 前端拿到结果后，取 end($list)['id'] 作为 next_cursor，下一次请求带上这个值即可。

这种方法的好处很明显：不管翻到第多少页，每次查询都只读极少量的行，性能恒定，不会随着页码增大而变慢。

游标分页在 ThinkPHP 模型里怎么封装才安全

别把游标逻辑散落在控制器里——那是新手容易踩坑的地方。正确的做法是把它收口到模型方法中，既方便校验也方便复用。

• 使用 $this->getPk() 动态获取主键名，千万别硬写 'id'，否则换表就得改代码。
• 接收到的 $cursor 值必须做类型校验：整数字段用 intval()，时间字段需要确认格式（比如统一的 Y-m-d H:i:s）。
• 返回结构里必须包含 next_cursor，当没有更多数据时显式设为 null，这样前端能准确判断是否翻到了底。
• 不要在模型里写死表名，用 $this->getTable()；同时避免用 Db::name() 绕过模型，否则会丢失事件、自动转换等模型能力。
• 特别提醒：created_at 这类时间字段如果单独作为游标，毫秒级重复可能会导致漏数据。稳妥的做法是组合 created_at + id，比如 WHERE (created_at, id) > (?, ?)，这样唯一性才有保障。

哪些场景不适合强行上游标分页

游标分页虽然快，但也不是免费的午餐。它有一个核心代价：放弃了随机跳页，也放弃了精确的总条数统计。如果产品需求非要支持“跳到第 382 页”，那游标分页就无能为力了，只能另想办法。

• 用户能手动输入页码的场景（比如后台管理列表）：游标无法满足，可以考虑用延迟关联（JOIN (SELECT id FROM ... LIMIT offset, size)）或者按时间分区查询。
• 数据频繁删除或 ID 被回收（比如软删后 ID 重新利用）：游标值可能会失效，导致漏数据或者重复数据。
• 排序字段本身不稳定的情况（比如 status 变更频繁）：同一游标值在不同时间点查询结果可能不一致，用户体验会受影响。
• 需要精确展示“共 12486 条”这种总数：游标分页不该、也不能提供这个信息，因为 COUNT(*) 本身在大数据量下就已经成为瓶颈。

最后说一个容易被忽略的致命点：游标值本质上不是“页码”，它是数据快照的位置信息。前端传错、后端没校验、排序字段索引缺失——这三个环节只要有一个出问题，分页就会悄无声息地漏数据或重复数据，而且很难被日志发现。所以，封装游标分页时，校验和索引检查一定要做在前面。