PHP 过滤已读内容

wen PHP项目 2026-08-10 5

PHP高效过滤已读内容：从基础到进阶的完整指南

目录导读

为什么需要过滤已读内容？ – 用户场景与性能痛点
基础实现：用Session标记已读状态 – 简单但有限
进阶方案：数据库驱动的内容追踪 – 持久化与精准过滤
性能优化：缓存与索引的巧妙结合 – 应对大数据量
实战问答：常见陷阱与解决方案
总结与最佳实践

在开发新闻聚合器、论坛系统或即时通讯工具时，“已读/未读”功能几乎是标配，用户希望一眼看出哪些新内容，而系统则需要高效地过滤掉已被用户标记为“已读”的记录，避免重复展示，随着用户量和内容量的增长，简单的PHP array_diff 或 WHERE id NOT IN (...) 会迅速演变成性能灾难，本文将深度剖析PHP过滤已读内容的多种实现层级，从轻量级Session方案到高并发数据库优化，并附上针对搜索引擎收录（Bing/Google）的语义结构建议。

PHP 过滤已读内容

为什么需要过滤已读内容？核心场景与痛点

用户体验：未读角标、高亮新帖、避免重复阅读记忆负担。
后端压力：若不过滤，数据库每次查询都要全量返回，导致网络I/O和PHP内存膨胀。
典型误区：很多开发者直接在SQL中使用 NOT IN (SELECT article_id FROM read_log WHERE user_id = ?)，当已读记录超过几千条时，该子查询会耗尽临时表空间,查询速度呈指数级下降。

基础入门：Session + Cookie方案（适合轻量级场景）

对于无需跨设备同步的小型应用（如单用户后台面板）,可用Session存储已读ID数组。

代码示例（伪代码）：

// 标记已读
$_SESSION['read_items'][$content_id] = time();
// 过滤查询前的ID数组
$read_ids = array_keys($_SESSION['read_items'] ?? []);
// 构造查询
$query = "SELECT * FROM articles WHERE status='active'";
if (!empty($read_ids)) {
    $placeholders = implode(',', array_fill(0, count($read_ids), '?'));
    $query .= " AND id NOT IN ($placeholders)";
    $stmt = $pdo->prepare($query);
    $stmt->execute($read_ids);
}

局限：Session默认文件存储，超过5MB会拖慢PHP进程,且无法跨设备同步。

进阶方案：数据库持久化 + 布尔索引（核心推荐）

真正高效的做法是建立独立的阅读记录表，并利用复合索引与左连接排除法。

表结构设计（MySQL示例）：

CREATE TABLE `user_read_log` (
    `id` BIGINT UNSIGNED AUTO_INCREMENT,
    `user_id` INT UNSIGNED NOT NULL,
    `content_id` INT UNSIGNED NOT NULL,
    `read_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (`user_id`, `content_id`),  -- 复合主键防重复
    KEY `idx_user_time` (`user_id`, `read_at`) -- 用于按时间排序
) ENGINE=InnoDB;

高效查询逻辑（LEFT JOIN + IS NULL）：这是替代 NOT IN 的黄金标准，它避免了子查询的临时表开销,且能利用索引。

$sql = "SELECT a.* FROM articles a
        LEFT JOIN user_read_log r 
               ON a.id = r.content_id AND r.user_id = :uid
        WHERE a.status = 1 
          AND r.id IS NULL  -- 关键过滤
        ORDER BY a.created_at DESC
        LIMIT 20";

原理：MySQL优化器对LEFT JOIN ... IS NULL的优化往往优于NOT EXISTS,特别是在有复合主键约束时。

性能优化：应对百万级已读记录

当单个用户已读内容超过1万条时，上面的JOIN依然会变慢，此时需要引入冗余字段或外部缓存。

方案A：内容表增加 last_read_at 字段，在文章表中冗余一个时间戳，每次读时更新当前用户的最新阅读时间（需配合用户表存储全局最新时间），但仅适合“全局已读”逻辑,不适合逐条已读。
方案B：使用Redis Set存储已读ID（推荐），将已读ID存入Redis Set（set:read:{user_id}），查询时，先批量从Redis取ID，然后利用分片策略（如按时间分桶），再执行 WHERE id IN (...) 排除,但不要超过1000个ID。
方案C：位图压缩，对于整数连续ID，可用位图（pack()）将已读状态压缩至1/8大小,但维护复杂。

实用建议：对于绝大多数中小型应用，“JOIN + 复合索引”方案已足够，只有当单用户已读量超过5万条,再考虑引入Redis或分表。

实战问答：常见陷阱与解决方案

Q1：为什么我用 WHERE id NOT IN (SELECT content_id FROM user_read_log WHERE user_id=1) 在数据量小时快，数据量大了就慢？
A：NOT IN 中的子查询在MySQL 5.7前的版本会物化为临时表，且无法有效利用索引，而LEFT JOIN ... IS NULL 可以通过 user_read_log 的复合主键（user_id, content_id）进行Nested Loop查找，内存占用小,速度稳定。

Q2：如何高效统计“未读数量”？
A：不要使用 COUNT(*) 去排除，而是维护一个unread_count冗余字段在用户表，当用户点击进入内容详情页时，事务内执行 UPDATE users SET unread_count = unread_count - 1 WHERE id=? AND unread_count > 0，随后异步写入阅读日志，这对高并发场景（如消息App）至关重要。

Q3：如果有多个内容类型（文章、视频、评论）需要过滤，怎么办？
A：将 content_id 改为 item_id 并增加 item_type 字段，复合主键改为 (user_id, item_type, item_id)，查询时用 (r.item_type = 'article' AND r.item_id = a.id) 作为JOIN条件。

Q4：如何避免“已读”数据无限增长？
A：规划一个 “只保留最近180天已读记录” 的清理任务（CRON），对于超过时间的数据，用户通常不关心，定期执行 DELETE FROM user_read_log WHERE read_at < DATE_SUB(NOW(), INTERVAL 180 DAY)，在业务层面，若用户历史深挖需要,可迁移至归档表。

Q5：在分页场景下，过滤已读内容的最佳实践？
A：若列表页有“只看未读”按钮，分页逻辑必须基于游标分页而不是 LIMIT offset，否则已读内容会挤掉新内容导致重复显示，使用 WHERE a.id > last_seen_id AND ... 配合 ORDER BY a.id ASC 可解决。

总结与最佳实践

首选方案：数据库 LEFT JOIN + IS NULL + 复合主键，简单、可靠、无需额外组件。
次选：若已读量巨大且并发极高，采用Redis存储Set,并需处理预热与穿透问题。
代码层面：务必使用预处理语句,防止SQL注入。
SEO与文章结构：正如本文目录所示，清晰的H标签和语义化段落有助于Bing和Google理解内容，在实现“过滤已读”的同时，建议为已读内容生成 <del> 或降低透明度的样式，但不要 display:none,这会影响页面可访问性与蜘蛛抓取。

请记住：没有万能的银弹，在真实项目中，请先用 EXPLAIN 分析你的查询，再决定是否引入缓存，优秀的架构是权衡后的产物,而非一味堆砌技术。