PHP分页缓存技巧提升加载速度

本文深入剖析了PHP分页性能瓶颈的根本原因——传统LIMIT+OFFSET查询无法复用执行计划、导致数据库反复扫描与索引失效，并指出单纯缓存HTML或依赖COUNT(*)会加剧性能恶化；文章主张转向更高效的游标分页模型，强调应手动缓存分页元数据（如总条数、ID范围）和结构化数据块（以主键为游标、Redis为载体），通过“page:article:cursor_1280:size_20”等可预测键名实现高命中率缓存，同时给出缓存写入、预热、失效及搜索场景下的替代方案（如ID列表+zset分页），并警示开发者：缓存必须与分页逻辑严格对齐，否则适得其反。

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，又让缓存键可预测、可预热。

• 缓存键建议用 "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(*) 每次都算——这两者底层逻辑冲突，强行混用只会让问题更难定位。

以上就是《PHP分页缓存技巧提升加载速度》的详细内容，更多关于的资料请关注golang学习网公众号！