PHP分页查询缓存优化方法

文章小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《PHP分页查询缓存优化技巧》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

应缓存静态榜单等读多写少场景，键用确定性拼接，值用json_encode序列化，高偏移量改用游标分页防击穿，避免LIMIT OFFSET性能陷阱。

缓存分页结果前先确认是否真能缓存

分页查询缓存不是万能的，尤其当数据实时性要求高、用户登录态影响结果（如权限过滤）、或 ORDER BY 字段频繁更新时，缓存反而导致脏数据。真正适合缓存的是「静态榜单」「商品分类列表」「博客归档页」这类读多写少、排序稳定、无个性化逻辑的场景。

关键判断点：
• 分页 SQL 中不含 WHERE user_id = ? 或 session_id 类动态条件
• 排序字段（如 created_at）更新频率低于缓存 TTL（比如每小时更新不到 10 次）
• 总记录数 COUNT(*) 不随每次请求重算（应单独缓存或用近似值）

用 Redis 缓存分页数据块而非整页 HTML

别把 render_page_html() 的输出直接塞进 Redis——HTML 体积大、难以复用、无法按需更新某一页。正确做法是缓存「数据块」：即 SELECT id, title, updated_at FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 40 返回的数组。

实操建议：
• 键名用确定性拼接，例如 "page:posts:by_created:20:40"（表示每页 20 条、第 3 页）
• 值序列化用 json_encode()，避免 serialize() 的 PHP 版本兼容问题
• 设置 TTL 略高于业务容忍延迟，比如 600 秒（10 分钟），并配合「惰性删除 + 主动刷新」策略
• 若总条数变化，只删 "count:posts:by_created" 键，不影响已有分页数据块

跳页时避免缓存击穿和雪崩

用户猛点第 1000 页，而该页从未被访问过，此时大量并发请求会同时穿透缓存去查 DB，还可能触发重复缓存写入。这不是理论风险，真实日志里常看到 "SELECT ... LIMIT 20 OFFSET 19980" 突增。

应对方式：
• 对高偏移量（如 OFFSET > 5000）强制走游标分页（cursor-based pagination），不依赖缓存键映射
• 使用 Redis 的 SETNX（set($key, $val, ['nx', 'ex' => 60])）实现「缓存预占」：先尝试设键，成功者查库并写缓存，失败者等待 100ms 后重读缓存
• 预热常用页：后台定时请求前 5 页、热门标签下前 3 页，写入缓存

注意 MySQL 的 LIMIT OFFSET 在缓存失效后的性能陷阱

哪怕你缓存了第 1 页到第 10 页，一旦缓存全失效，首次请求第 50 页仍会执行 LIMIT 20 OFFSET 980——MySQL 还是得扫描前 980 行。这和有没有缓存无关，是 SQL 本身的问题。

所以必须搭配：
• 游标分页替代方案：用上一页最后一条的 created_at 和 id 作为条件，例如 WHERE created_at
• 在游标分页基础上再套缓存，键名可简化为 "page:posts:cursor:2023-01-01:12345"
• 禁止在缓存层做 OFFSET 计算，所有分页参数必须由业务层校验并转换为游标条件

最易被忽略的一点：缓存的「页大小」必须和 SQL 中的 LIMIT 严格一致，且不能在应用层对缓存结果再切片（比如缓存了 20 条却只显示 15 条），否则游标逻辑和缓存命中都会错乱。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《PHP分页查询缓存优化方法》文章吧，也可关注golang学习网公众号了解相关技术文章。