ThinkPHP大表分页性能优化，有哪些替代游标分页的方法？

本文共计1067个文字，预计阅读时间需要5分钟。

由于使用`paginate() 默认基于 OFFSET + LIMIT，数据量一旦超过百万，使用 OFFSET 50000 这类查询就会全表扫描到第五百万行，MySQL 执行计划里经常出现 `Using filesort` 或 `Using temporary`，导致 CPU 和 I/O 等资源压力巨大。

真实场景下，用户翻到第 200 页（每页 25 条）时，OFFSET 4999 已经明显卡顿；到第 1000 页，响应可能超 3 秒甚至超时。

• 不是 TP 框架问题，是 SQL 分页模型本身在大数据量下的通病
• paginate() 不支持自动改写为游标分页，得手动绕开
• 如果表没合适单调递增字段（比如 id 或 create_time），游标分页也难落地

ThinkPHP 实现游标分页的最小可行写法

核心思路：不用 OFFSET，改用 WHERE id > ? ORDER BY id LIMIT N，靠上一页最后一条记录的 id 做“锚点”。

示例（TP 6.x）：

立即学习“PHP免费学习笔记（深入）”；

$lastId = input('last_id', 0, 'intval'); $perPage = 20; $list = Db::name('article') ->where('id', '>', $lastId) ->order('id ASC') ->limit($perPage) ->select(); // 返回数据 + 下一页的 last_id（即本页最后一条的 id）

• 必须确保排序字段有索引，且值唯一或基本不重复（id 最稳妥，create_time 要加 id 作为第二排序条件防歧义）
• 不能用 DESC 方向做“上一页”，得反向查（比如上一页实际是 WHERE id ），逻辑要自己兜住
• input('last_id') 必须校验非负整数，否则 SQL 注入风险直接暴露

游标分页和传统分页在 ThinkPHP 中的兼容处理

业务不可能一夜全切游标分页——搜索页要跳页、后台管理要页码输入，这些还得靠 paginate()；但列表流加载（如信息流、订单流）必须上游标。

• 不要强行统一接口返回格式，游标分页天然不带总条数、无总页数，硬塞 total 字段反而误导前端
• 共用一个控制器方法？可以，但要用参数区分模式：type=cursor vs type=page，路由或中间件提前拦截判断
• 注意缓存键设计：游标分页的缓存 key 必须包含 last_id 和 limit，不能只按 page=1 缓存
• TP 的 withTotalCount(false) 可关掉 count 查询，但只是省一次 SQL，没解决 offset 问题，别误以为这是优化

容易被忽略的边界情况和线上踩坑点

游标分页不是设个 last_id 就万事大吉，这几个点上线后才暴雷：

• 新数据插入导致“漏数据”：用户滑到末尾时，另一端刚插入几条 id 更小的记录，下次请求 last_id 之后就跳过了——解决方案是让前端传“时间戳+id”双锚点，或强制按 create_time DESC, id DESC 排序
• 删除记录造成“重复数据”：A、B、C 三条记录，用户看完 A B 后 B 被删，再请求 last_id=A.id 会把 C 当作下一条，但 B 缺失导致 C 被重复刷出——本质是游标分页不保证全局一致性，需接受最终一致
• TP 的 order() 如果写成 order('create_time desc, id desc')，但数据库里 create_time 是 datetime(0)，而 PHP 写入时带毫秒，排序错乱——统一用 datetime(3) 或全切 id 排序最稳

游标分页真正的门槛不在代码怎么写，而在你愿不愿意放弃“第 N 页”这个思维惯性，以及能不能跟产品讲清：滚动加载没有“跳到第 87 页”的能力，只有“继续往下看”。