最稳妥的是用 Redis 的 ZSET 存原始排序数据（score=排序字段值，member=主键ID），再配合 ZRANGE + ZCARD 做分页和总数统计——前提是排序字段唯一且稳定。
分页数据存Redis用什么结构最合适
直接存整个分页结果数组到字符串（SET）看似简单，但更新某一页或删数据时无法局部刷新，容易脏；用哈希（HSET）按页号存也行，但分页总数、总条数这些元信息得额外维护，不统一。最稳妥的是：**用 Redis 的 ZSET 存原始排序数据（score=排序字段值，member=主键ID），再配合 ZRANGE + ZCARD 做分页和总数统计**——前提是排序字段唯一且稳定（比如 created_at + id 拼接作 score）。
如果排序字段不唯一（如多个记录同时间创建），必须加唯一后缀避免 member 冲突，例如：
zadd articles:2024:score 1698765432.000001:1001 1001<br>zadd articles:2024:score 1698765432.000002:1002 1002
- 分页查：用
ZRANGE articles:2024:score $offset $limit WITHSCORES - 总数：
ZCARD articles:2024:score，比GET一个预存总数更可靠 - 翻页跳转快：
ZRANK可定位某 ID 当前页码，适合“回到上次位置”场景 - 注意：
ZSET不支持 offset-limit 随机跳转的 O(1) 复杂度，大数据量（>10w）时ZRANGE偏移过大仍会慢，此时应改用游标式分页（SCAN或业务层游标）
缓存分页元信息该不该单独存
必须存，而且要和数据缓存联动失效。比如用 GET page:articles:2024:meta 存 {"total": 1284, "per_page": 20, "last_updated": 1712345678} ——这不是可选优化，是避免并发写入导致总数错乱的关键。
- 每次新增/删除记录后，立刻
INCR或DECR总数（用INCRBY更安全） - 不要依赖
ZCARD实时算总数：高并发下可能因 pipeline 或网络延迟产生瞬时不一致 - 元信息设 1–3 秒过期（
EXPIRE），配合写后更新，既防雪崩又保最终一致 - 如果业务允许弱一致性（如后台管理页），可省掉元信息，直接
ZCARD查总数；但用户端列表页不建议
PHP 里怎么安全读取带分页的 ZSET 数据
别用 redis->zRange() 直接传 $page * $limit 算 offset——当有人恶意传 page=999999，Redis 会遍历前几百万元素再返回空数组，拖垮服务。
立即学习“PHP免费学习笔记（深入）”；
正确做法是先用 ZCARD 判断范围，再截断：
$total = $redis->ZCARD('articles:2024:score');<br>$offset = max(0, min($page - 1, (int)(($total - 1) / $per_page))) * $per_page;<br>$ids = $redis->zRange('articles:2024:score', $offset, $offset + $per_page - 1);- 用
max/min截断 offset，防止越界计算 - 查出 ID 后，再用
MGET批量查详情（假设详情存在article:1001这类 key） - 不要在 PHP 里用
foreach单条查 Redis，MGET 能减少 90%+ 的 RTT - 如果详情数据也需缓存，建议用
PIPELINE一次发多个命令，但注意超时和内存占用
什么时候该放弃 Redis 分页缓存
不是所有分页都适合上 Redis。以下情况直接走 MySQL LIMIT OFFSET 更省事、更稳：
- 数据实时性要求极高（秒级更新），且写远大于读（如 IM 消息流）
- 排序逻辑复杂（涉及多表 JOIN、函数计算、用户权限过滤），无法预热进 ZSET
- 分页条件动态多变（如搜索关键词频繁变），ZSET 结构难以覆盖全部组合
- 单页数据量极小（
真正值得投入 Redis 分页的，是那些「排序固定、读多写少、总量大、分页稳定」的场景，比如文章归档、商品类目列表、日志查询后台——其余情况，先压测再决定。
