PHP分页查询缓存优化技巧

本文深入剖析了PHP分页查询中缓存优化的关键实践与避坑指南，强调缓存并非万能解药——仅适用于静态榜单、商品分类、博客归档等读多写少、排序稳定且无用户个性化逻辑的场景；提出以Redis缓存结构化数据块（而非HTML）、采用确定性键名拼接和json_encode序列化、结合惰性删除与主动刷新策略，并重点指出高偏移量下必须用游标分页替代LIMIT OFFSET以规避数据库扫描性能陷阱和缓存击穿风险，同时给出预占锁、页预热、TTL设计等落地细节，帮你真正实现高效、安全、可维护的分页缓存。

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

分页查询缓存不是万能的，尤其当数据实时性要求高、用户登录态影响结果（如权限过滤）、或 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学习网公众号，给大家分享更多文章知识！