ThinkPHP默认paginate()在十万级以上数据深度翻页时严重变慢，因其强制执行COUNT(*)+LIMIT offset,size，MySQL需扫描丢弃前N行；应改用simple分页或游标分页，并确保索引设计匹配查询逻辑。
ThinkPHP 默认 paginate() 在十万级以上数据翻页就会明显变慢，不是配置调大就能解决——它底层强制执行 COUNT(*) + LIMIT offset, size，MySQL 必须扫描并丢弃前 N 行，IO 和 CPU 双重拉满。
为什么 paginate() 一查就卡死？
典型表现：第 100 页开始加载超时、CPU 占用飙升、日志里没报错但页面白屏。这不是 TP 框架缺陷，而是 SQL 层面的反模式。
-
SELECT COUNT(*) FROM user WHERE status = 1：哪怕加了status索引，也可能走全表扫描，耗时秒级 -
SELECT * FROM user WHERE status = 1 ORDER BY id DESC LIMIT 99980, 20：MySQL 要定位到第 99980 行起点，再取 20 条，offset 越大越慢 - 两者叠加，TP 默认分页在真实业务中基本不可用于深度翻页
关闭 totalCount + 改用 simple 分页
如果前端不需要显示“共 XX 页”或跳转任意页码，这是最快见效的优化点。
- 控制器中调用：
$list = Db::name('order')->where('user_id', $uid)->paginate(20, false); - 模板中渲染：
{$list->simple()->appends(request()->param())->render()}——appends()必须显式加，否则翻页丢失搜索参数 - 效果：跳过
COUNT(*)，只查数据 + 判断是否有下一页，响应从秒级降到毫秒级
必须用游标分页的场景
当数据量稳定在百万级、且用户行为是“下一页/上一页”连续浏览（如后台日志、消息流、订单列表），游标分页是唯一靠谱方案。
立即学习“PHP免费学习笔记（深入）”；
- 前提：分页字段必须有索引，且严格有序（推荐主键
id或带索引的create_time） - 不能混用
paginate()参数，比如simple、query对游标无效 - 示例（按
id ASC）：$list = Db::name('user')->where('id', '>', $lastId)->where('status', 1)->order('id ASC')->limit(20)->select(); - 坑点：order 方向必须和 where 条件一致（
>对应ASC，<对应DESC），写反直接退化为全表扫描
索引与字段设计不能省
游标分页快不快，最终取决于 MySQL 能不能用索引直接定位起始行。
- 执行
EXPLAIN SELECT * FROM order WHERE user_id = 123 ORDER BY create_time DESC LIMIT 20;，确认type不是ALL，key显示实际索引名 - 建联合索引：
ALTER TABLE `order` ADD INDEX idx_uid_ctime (user_id, create_time DESC);—— 字段顺序和方向必须匹配查询逻辑 - 确保字段
NOT NULL，避免因空值导致索引失效 - 时间字段慎用
datetime（精度低、易重复），优先用bigint存纳秒时间戳或自增id
真正难的不是写对一行 where('id', '>', $lastId)，而是判断当前业务是否允许放弃“跳转任意页”这个幻觉——多数后台场景其实只需要“下一页”，而用户根本不会翻到第 500 页，只是接口被爬虫或导出脚本触发了深偏移而已。
