ThinkPHP分页优化：索引设计如何提升分页查询近9倍速度

分页变慢的根源，其实可以归结到一点：paginate() 在大数据量下硬扛 COUNT(*) 加 LIMIT offset, size，本质是 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 左右，而不是 50 万

行内常见的反例：WHERE name LIKE '%abc' 或 whereRaw('DATE(create_time) = ...')。哪怕字段有索引，key 也必定是 NULL。

必须正视的 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
• 如果非要精确总数还不能缓存，那就改成异步任务更新总数，接口返回“总数约 XX，实时数据已加载”

最后一点往往被忽视：索引建得再好，如果 paginate() 还在用 OFFSET，一旦页码超过 1000，性能就会断崖式下跌。到了这个地步，该换游标分页了，而不是继续在索引上死磕。