PHP如何实现高效分页功能详解

本文深入剖析了PHP中高效分页的实战策略，直击传统OFFSET分页在大数据量下性能断崖式下跌的痛点，力推游标分页作为更优解——通过利用唯一有序字段（如id）作为查询起点，彻底规避全表扫描；同时强调安全底线：严格校验用户输入、杜绝未过滤参数直连SQL、分离并合理缓存总数统计，并规范分页URL参数传递逻辑，帮助开发者在性能、安全与用户体验之间找到精准平衡。

分页时 OFFSET 越大越慢，怎么办

MySQL 的 LIMIT offset, size 在 offset 很大时（比如 100 万行后取 20 条），会真实扫描前 offset + size 行再丢弃，性能断崖式下跌。

真正高效的做法是「游标分页」（Cursor-based Pagination）：用上一页最后一条记录的排序字段值作为下一页起点，避免依赖 OFFSET。

• 适用场景：列表按时间/ID 严格递增、不频繁更新、不要求跳转任意页（如日志流、消息流）
• 关键点：必须有唯一且有序的索引字段，比如 id 或 created_at + id
• 示例 SQL：SELECT * FROM posts WHERE id > 12345 ORDER BY id ASC LIMIT 20（上一页最后一条 id 是 12345）
• PHP 中需校验该 id 是否真实存在，防止被篡改或越界

$_GET['page'] 直接参与 SQL 拼接，很危险

用户传入的页码不加过滤就塞进 OFFSET 计算，等于给 SQL 注入开了后门。哪怕只是整数，也必须强制类型转换或白名单校验。

• 错误写法：$page = $_GET['page']; $offset = ($page - 1) * $size; —— $_GET['page'] 可能是 1; DROP TABLE users;
• 正确做法：用 (int) 强转 + 边界检查，例如 $page = max(1, (int)$_GET['page']);
• 更稳妥：用 filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT)，失败返回 false
• 永远不要把未处理的 $_GET 或 $_POST 值拼进 SQL，哪怕你“确定”它只是数字

总数查询 COUNT(*) 和分页查询分离，别合在一个事务里硬扛

显示「共 12847 条，第 3 页 / 共 643 页」看起来合理，但每次请求都执行 SELECT COUNT(*) FROM ... WHERE ...，尤其带复杂 JOIN 或 WHERE 条件时，I/O 和 CPU 开销巨大。

• 可接受方案：缓存总数（如 Redis 存 post_count_v2），仅在数据批量变更后刷新
• 轻量替代：用 SQL_CALC_FOUND_ROWS（已废弃）或两次查询（不推荐），不如直接放弃精确总页数
• 更现实的做法：只查当前页数据 + 多查一条，判断是否有下一页（LIMIT 21，只展示前 20 条），不显示总页数
• 注意：COUNT(*) 在 InnoDB 上仍需扫描索引，不是 O(1)，表越大越明显

分页链接里的参数没处理好，URL 乱成一团

用户在搜索页翻页，结果 ?q=php&page=2 变成 ?page=2，搜索条件丢了；或者多个筛选参数重复叠加，生成 ?cat=1&cat=2&sort=date&sort=title。

• 核心思路：用 http_build_query(array_merge($_GET, ['page' => $next])) 维持原有参数
• 记得先 unset($_GET['page']) 再合并，避免 page 参数冲突
• 对敏感参数（如 token、signature）要主动过滤，别一股脑带过去
• URL 编码问题：中文或特殊字符在 $_GET 中已是解码状态，http_build_query 会自动再编码，无需手动 urlencode

分页看着简单，但每一步都在和数据库、HTTP、用户预期较劲。最容易被忽略的是：游标分页无法跳转任意页，而传统分页又扛不住大数据量——选哪种，得先想清楚你的「下一页」到底意味着什么。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~