php分页需手动加缓存，因limit+offset无法复用结果且性能差；应缓存分页元数据和数据块，用主键范围查询+redis游标式缓存（如page:article:cursor_1280:size_20），避免offset与count(*)混用。
PHP分页本身不带缓存，缓存必须手动加；不加缓存的分页在数据量大、访问频繁时，每次请求都查库、计算总条数、OFFSET 跳过大量行，性能会断崖式下跌。
为什么分页查询不能靠数据库 LIMIT + OFFSET 缓存？
因为 LIMIT 10 OFFSET 1000 这类语句无法复用结果——OFFSET 值一变，数据库就得重新扫描前 N 行，MySQL 甚至可能放弃索引。即使你把整页 HTML 缓存了，只要用户翻页，就又得走一遍慢查询。
真正要缓存的是「分页元数据」和「分页数据块」，而不是渲染后的 HTML（除非页面极度静态）。
-
COUNT(*)结果变化不频繁时，可缓存总条数（比如 5–30 分钟） - 每页的
id范围（如min_id/max_id）比OFFSET更适合缓存和复用 - 用主键范围查询（
WHERE id > ? ORDER BY id LIMIT 20）比OFFSET快一个数量级，且天然支持游标式缓存
用 Redis 缓存分页数据块的实操要点
别缓存“第 3 页”，缓存“从 id=1280 开始的 20 条”。这样既规避 OFFSET，又让缓存键可预测、可预热。
立即学习“PHP免费学习笔记（深入）”；
- 缓存键建议用
"page:article:cursor_{$last_id}:size_20"，而非"page:article:page_3" - 写入缓存时带上
TTL（如3600秒），避免脏数据长期滞留 - 缓存未命中时，用主键范围查询补数据，并顺手把下一页的起始
id也查出来（减少下次查询） - 更新/删除记录后，清掉相关缓存段（如
DEL page:article:cursor_*或用前缀批量删，Redis 6+ 支持SCAN+DEL）
示例片段：
$cacheKey = "page:article:cursor_{$lastId}:size_20";
$data = $redis->get($cacheKey);
if ($data === false) {
$stmt = $pdo->prepare("SELECT * FROM article WHERE id > ? ORDER BY id LIMIT 20");
$stmt->execute([$lastId]);
$data = $stmt->fetchAll(PDO::FETCH_ASSOC);
$redis->setex($cacheKey, 3600, json_encode($data));
}什么时候该放弃分页缓存，改用搜索缓存？
当分页叠加了复杂条件（如多字段模糊搜索、时间范围、状态筛选），缓存键爆炸式增长（page:search:status_1:cat_5:q_php:page_7），缓存命中率会趋近于 0。
- 这种场景下，优先考虑把整个搜索结果集 ID 列表缓存（如
"search:hash_abc123"），再分批取详情 - 用
zset存 ID + score（如发布时间），天然支持分页跳转和自动去重 - 避免在 PHP 层做
array_slice，ID 列表缓存后，用ZRANGE search:hash_abc123 200 219直接取第 11 页 ID - 注意：ID 列表缓存需配合布隆过滤器或异步双删，防止详情数据已更新但列表未刷新
最常被忽略的一点：缓存不是加了就快，而是要和你的分页模型对齐。用 OFFSET 就别硬套游标缓存，用游标就别留着 COUNT(*) 每次都算——这两者底层逻辑冲突，强行混用只会让问题更难定位。
