ThinkPHP 6.0 中 paginate() 在大数据量下变慢的根本原因是 MySQL 必须扫描并丢弃前 offset 行，导致 IO 浪费；优化方案包括：用子查询先取 ID 再 JOIN 回表、关闭 COUNT(*)（传 false）、或改用游标分页。
ThinkPHP 6.0 中 paginate() 生成的 LIMIT offset, size 查询在数据量超 50 万后明显变慢，第 1000 页响应常超 2 秒——这不是框架缺陷，而是 MySQL 必须扫描并丢弃前 offset 行导致的 IO 浪费，尤其当查询含 JOIN 或 WHERE 条件未命中索引时，性能断崖式下跌。
用子查询先捞 ID 再关联主表
第一步：确认当前分页 SQL 的执行计划。在控制器中调用 $model->getLastSql() 获取真实语句，粘贴进 MySQL 执行 EXPLAIN，重点看 type 是否为 ALL、rows 是否接近总行数、key 是否为 NULL。若三项全中，说明已触发全表扫描。
第二步：手动改写分页逻辑，放弃 paginate()，改用两段式查询。先查出目标页的主键 ID 列表，再用这些 ID 拉取完整字段。
第三步：构造子查询 SQL。例如原语句是 UserModel::where('status', 1)->order('id desc')->paginate(20)，替换为：
立即学习“PHP免费学习笔记（深入）”；
SELECT u.* FROM user u INNER JOIN ( SELECT id FROM user WHERE status = 1 ORDER BY id DESC LIMIT 9980, 20 ) AS tmp ON u.id = tmp.id
注意：子查询里只 SELECT id 字段，且必须带 ORDER BY + LIMIT，否则 MySQL 无法利用主键聚集索引快速定位；外层 JOIN 能复用主键索引回表，避免全字段扫描。
第四步：在 ThinkPHP 6.0 中用 Db::query() 执行该 SQL。需绑定参数防注入：$this->query($sql, [1])，其中 [1] 对应 status = ? 的值。不要用 Db::table()->select() 封装，它会自动加额外 WHERE 和别名，破坏子查询结构。
JOIN 场景下的延迟关联改写
方法一：原始带 JOIN 的慢查询（如订单+用户信息）
SELECT o.*, u.username FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE o.status = 1 ORDER BY o.id DESC LIMIT 10000, 20
这会导致 MySQL 先 JOIN 出全部匹配记录，再排序丢弃前 10000 行——中间结果集可能达百万行。
方法二：拆成两步，用延迟关联优化
先执行轻量级 ID 查询：SELECT id FROM orders WHERE status = 1 ORDER BY id DESC LIMIT 10000, 20
拿到 20 个 order_id 后，再查完整数据：SELECT o.*, u.username FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE o.id IN (10001,10002,...,10020)
这一步必须显式列出所有 ID，不能传数组给 IN —— ThinkPHP 的 whereIn('id', $ids) 会拼成预处理占位符，MySQL 无法对 IN 列表做索引优化；要手拼字符串或改用 Db::execute() 执行原生 SQL。
【关键前提】orders.id 必须有主键或唯一索引，否则 IN 查询仍会走全表扫描
绕过 COUNT(*) 的硬性开销
ThinkPHP 默认 paginate() 会执行两次查询：一次 COUNT(*) 统计总数，一次 LIMIT 取数据。500 万行表上 COUNT(*) 耗时常超 3 秒。
关闭自动统计总数：在 paginate() 第二个参数传 false，例如 $model->paginate(20, false)。此时分页器不提供总页数和总条数，但返回数据、上一页/下一页链接仍正常。
若前端必须显示“共 XX 条”，改用覆盖索引 COUNT：在 WHERE 条件字段和主键上建联合索引，例如 ALTER TABLE orders ADD INDEX idx_status_id (status, id)，再用 SELECT COUNT(id) FROM orders WHERE status = 1 替代 COUNT(*)。
这步操作后，COUNT 查询 rows 从 500 万降至 20，响应时间从秒级压到毫秒级。
