应缓存静态榜单等读多写少场景，键用确定性拼接，值用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" 键，不影响已有分页数据块
立即学习“PHP免费学习笔记（深入）”；
跳页时避免缓存击穿和雪崩
用户猛点第 1000 页，而该页从未被访问过，此时大量并发请求会同时穿透缓存去查 DB，还可能触发重复缓存写入。这不是理论风险，真实日志里常看到 "SELECT ... LIMIT 20 OFFSET 19980" 突增。
citySHOP是一款集CMS、网店、商品、系统，管理更加科学快速；全新Jquery前端引擎；智能缓存、图表化的数据分析，手机短信营销；各种礼包设置、搭配购买、关联等进一步加强用户体验；任何功能及设置都高度自定义；MVC架构模式，代码严禁、规范；商品推荐、促销、礼包、折扣、换购等多种设置模式；商品五级分类，可自由设置分类属性；商品展示页简介大方，清晰，图片自动放大，无需重开页面；商品评价、咨询分开
应对方式：
• 对高偏移量（如 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 条），否则游标逻辑和缓存命中都会错乱。
