ThinkPHP百万级数据分页卡死是因为paginate()强制全表COUNT和大offset LIMIT，导致MySQL扫描丢弃大量行；应改用基于主键/时间戳的游标分页，通过where+order+limit避免性能衰减。
ThinkPHP 数据库分页在百万级数据下响应超时、CPU 占用飙升，是因为默认 paginate() 强制执行全表 COUNT 并配合大 offset LIMIT，MySQL 必须扫描并丢弃前 N 行，IO 和 CPU 双重浪费——这不是框架缺陷，而是 SQL 本身反模式。
为什么 paginate() 在大数据量下会卡死
ThinkPHP 调用 paginate(20) 时，底层自动生成两条 SQL：
① SELECT COUNT(*) FROM user WHERE status = 1 → 全表扫描，耗时 2s+；
② SELECT * FROM user WHERE status = 1 LIMIT 100000, 20 → MySQL 跳读 10 万行后才取 20 条，磁盘 I/O 拉满。
哪怕加了 status 字段索引，COUNT(*) 仍可能走全表；而 LIMIT 100000, 20 的性能衰减是非线性的，offset 每翻一倍，延迟不止翻倍。
【关键前提】游标分页仅适用于「按主键或时间戳严格递增/递减」的场景，且该字段必须有索引（最好是主键或联合索引最左前缀）。
立即学习“PHP免费学习笔记（深入）”；
改用游标分页：手写 where + order + limit
放弃 paginate()，直接用 Db 查询构造器拼接条件。
第一步：查第一页，取最后一条记录的 id
复制代码：$firstPage = Db::name('user')->where('status', 1)->order('id ASC')->limit(20)->select();
拿到 $lastId = end($firstPage)['id']; // 假设为 100500
第二步：查下一页，用 where('id', '>', $lastId)
复制代码：$nextPage = Db::name('user')->where('id', '>', 100500)->where('status', 1)->order('id ASC')->limit(20)->select();
注意：order 方向必须和 where 条件一致。> 对应 ASC，
这一步操作起来很简单，但漏掉 order 或方向反了，查询会退化为全表扫描。
在模型中封装游标分页方法
避免每次手写重复逻辑，把游标逻辑收进 UserModel。
方法一：基础封装（推荐）
在 UserModel.php 中添加：
public function cursorPaginate($lastId = 0, $size = 20, $where = []) {
$query = $this->where($where);
if ($lastId > 0) {
$query = $query->where('id', '>', $lastId);
}
return $query->order('id ASC')->limit($size)->select();
}
调用：$users = (new UserModel())->cursorPaginate(100500, 20, ['status' => 1]);
方法二：支持上一页（需反转结果）
查上一页时用 where('id', '
【不可逆操作】游标分页不返回总条数、无总页数，前端必须改用「下一页」按钮，不能渲染页码栏——否则用户点第 5000 页会触发非法请求。
替代 COUNT(*) 的轻量判断方案
若前端仍需“是否还有下一页”，禁用 SELECT COUNT(*)。
方法1：只查 21 条判断
复制代码：$probe = Db::name('user')->where('id', '>', $lastId)->where('status', 1)->limit(21)->select();
if (count($probe) > 20) { // 说明至少还有第 21 条，即存在下一页 }
方法2：用 SHOW TABLE STATUS 获取估算值（InnoDB 不精确，仅作参考）
复制代码：$rows = Db::query("SHOW TABLE STATUS LIKE 'user'")[0]['Rows'];
方法3：业务允许时，彻底去掉总数显示，点击「下一页」后查不到数据再提示“到底了”。
