ThinkPHP 的 paginate() 分页变慢是因为其基于 OFFSET + LIMIT，大数据量时 MySQL 需扫描大量行，导致 Using filesort 或 Using temporary；应改用游标分页，如 WHERE id > ? ORDER BY id LIMIT N，并确保排序字段有唯一索引。
ThinkPHP 用 paginate() 查大表为什么越来越慢
因为 paginate() 默认基于 OFFSET + LIMIT，数据量一过百万，OFFSET 50000 这类查询就得全表扫到第 5 万行，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=cursorvstype=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 页”的能力，只有“继续往下看”。
