PHP分页慢主因是COUNT(*)全表扫描；游标分页用WHERE id>last_id替代OFFSET，恒定高效，适用于Feed流等场景，但不支持任意页跳转。
直接查总数再分页，是 php 分页慢的最常见原因——count(*) 在大数据量 + 无覆盖索引时会全表扫描，比取数据还慢。
为什么 COUNT(*) 会拖垮分页？
mysql 对 select COUNT(*) FROM table WHERE ... 的执行逻辑取决于是否能走索引：
- 没合适索引时，InnoDB 必须遍历所有满足
WHERE条件的行（哪怕只想要第 100 页），实际开销可能远超SELECT * LIMIT 100,20 - 即使有索引，如果
WHERE条件涉及函数（如date(created_at)）、或范围过大（如status != 'deleted'），优化器仍可能放弃索引统计 -
SQL_CALC_FOUND_ROWS已被 MySQL 8.0 废弃，且在 5.7 中性能也不稳定，别用
用游标分页（Cursor-based Pagination）替代 OFFSET
适用于按时间、ID 等单调字段排序的场景，彻底绕过 OFFSET 跳跃和 COUNT 统计：
- 不查总页数，只提供「下一页」链接，前端用
last_id=12345或cursor=abc123请求 - 查询改写为：
SELECT * FROM posts WHERE id > 12345 ORDER BY id ASC LIMIT 20，可走主键索引，速度恒定 - 注意：不能跳转任意页，但对 Feed 流、日志列表等场景更自然，且抗写入干扰（新插入记录不影响已有分页结果）
- 若需双向翻页，加
ORDER BY id DESC+id 即可，但前后端需区分方向
真要显示总页数？试试估算或缓存
用户真的需要精确总页数吗？多数情况「约 2000+ 条」比「共 2347 条」体验更好，也更省资源：
立即学习“PHP免费学习笔记（深入）”；
- 用
SHOW TABLE STATUS LIKE 'table_name'查rows字段（MyISAM 准确，InnoDB 是估算值，误差可能达 40%，但够用） - 对不变或低频更新的列表，把
COUNT(*)结果缓存到 redis，设置合理过期时间（如 10 分钟），并配合业务更新事件主动清缓存 - 避免在分页接口里每次重算总数；把总数查询拆成独立异步任务或后台定时更新
索引和查询语句必须匹配分页逻辑
游标分页不是万能的——如果 WHERE 条件和 ORDER BY 字段没被同一个联合索引覆盖，照样慢：
- 例如分页语句是
WHERE status = 'published' ORDER BY created_at DESC，就要建INDEX(status, created_at)，而非单列索引 - 避免在
ORDER BY字段上用函数（如ORDER BY DATE(created_at)），这会让索引失效 - 用
EXPLAIN检查分页查询的key和rows：如果key为空或rows接近全表，说明索引没生效
分页慢的本质不是 PHP，而是 SQL 设计与索引协同出了问题。游标分页 + 合理索引覆盖，基本能解决 90% 的真实瓶颈；硬要保留传统页码，就得接受缓存或估算的妥协——没有银弹，只有权衡。