thinkphp分页变慢主因是paginate()在大数据量下执行count(*)+limit offset,size导致mysql全表扫描；应改用游标分页或子查询优化，并注意索引对齐、缓存、连接等隐性瓶颈。
分页变慢，90% 是因为 paginate() 在大数据量下硬扛 COUNT(*) + LIMIT offset, size——这不是 ThinkPHP 的锅，是 SQL 反模式。索引设计不对，再怎么调框架参数也白搭。
为什么加了索引分页还是慢？
常见错觉：只要字段上了索引，paginate() 就会快。实际中，WHERE 条件、ORDER BY 字段、主键顺序三者没对齐，索引就形同虚设。
-
WHERE status = 1 AND created_at > '2025-01-01'，却只建了(status)单列索引 →created_at段完全失效 -
ORDER BY id DESC，但id没索引或类型不匹配（比如传id = 123，而字段是VARCHAR）→ 触发Using filesort - 分页语句带
JOIN，关联字段（如user_id）没索引 → 先扫主表，再嵌套循环查关联表，rows翻倍暴涨
分页场景下必须建的联合索引组合
ThinkPHP 分页本质是「按某顺序取一段连续记录」，索引必须覆盖排序 + 过滤 + 主键三要素，否则优化器宁愿全表扫描。
- 最常用组合：
(status, created_at, id)—— 适配where('status', 1)->order('created_at desc')->paginate(20) - 游标分页必备：
(id)或(created_at, id)——where('id', '>', $last_id)->order('id asc')才能跳过 offset - 带 JOIN 的列表页：
orders.user_id和users.id都要有索引，且orders表上建(user_id, status, id)覆盖查询路径 - 别建
(created_at)单列索引：时间字段选择性低，配合WHERE时容易被优化器忽略
EXPLAIN 验证索引是否真生效
别信 buildSql() 输出的 SQL，它不执行也不走索引。必须用 getLastSql() 拿到真实语句，进 MySQL 执行 EXPLAIN 看三处：
-
type≠ALL（至少是range或ref） -
key显示实际使用的索引名（不是NULL） -
rows接近你预期的分页条数（比如取 20 条，rows是 25 而不是 500000）
一个典型反例：WHERE name LIKE '%abc' 或 whereRaw('DATE(create_time) = ...')，哪怕字段有索引，key 也必为 NULL。
paginate() 默认 count(*) 怎么绕过去
500 万行表，COUNT(*) 扫一遍就是 3 秒起。不是所有业务都需要精确总数——多数列表页用户根本不会翻到第 100 页。
- 关掉自动 count：
paginate(15, false, ['query' => request()->param()])，自己用缓存值或 Redis 计数器 - 用覆盖索引替代全表 count：
SELECT COUNT(id) FROM user WHERE status = 1（前提是id非空且在索引里） - 前端限制最大页码：
if ($page > 2000) { throw new HttpException(400); }，避免有人手输?page=100000 - 真正要精确总数又不能缓存？把
COUNT(*)改成异步任务更新，接口返回「总数约 XX，实时数据已加载」
最容易被忽略的一点：索引建对了，但 paginate() 还在用 OFFSET。只要页码超过 1000，性能断崖式下跌——这时候该切游标分页了，而不是继续堆索引。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
