本文介绍一种基于关系型数据库的轻量级通知系统设计，通过分离“通知模板”与“用户状态”两张表，避免消息重复存储，支持全局广播、已读标记及高并发写入。
本文介绍一种基于关系型数据库的轻量级通知系统设计，通过分离“通知模板”与“用户状态”两张表，避免消息重复存储，支持全局广播、已读标记及高并发写入。
在构建面向多用户的 Web 通知系统时，一个常见误区是为每位用户单独插入一条完整通知记录（如标题、内容、时间等），这不仅浪费存储空间，更会随用户量增长导致数据急剧膨胀、查询变慢、维护困难。正确的做法是采用“一对多”范式解耦：将通知内容本身抽象为独立实体，再通过关联表记录每个用户对该通知的交互状态。
✅ 推荐数据库结构设计
-- 1. notifications 表：仅存通知元数据（不重复） CREATE TABLE notifications ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(255) NOT NULL, content TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, is_active TINYINT(1) DEFAULT 1 -- 支持后台下架旧通知 ); -- 2. user_notifications 表：记录用户-通知关系与状态 CREATE TABLE user_notifications ( id BIGINT PRIMARY KEY AUTO_INCREMENT, notification_id INT NOT NULL, user_id INT NOT NULL, is_read TINYINT(1) DEFAULT 0, read_at DATETIME NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_notif (user_id, notification_id), -- 防止重复关联 FOREIGN KEY (notification_id) REFERENCES notifications(id) ON DELETE CASCADE, FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE );
? 关键设计说明：
- notifications 表每条记录代表一条逻辑通知（例如：“系统将于明日维护”），无论有多少用户接收，只存一次；
- user_notifications 表则为每个用户对每条通知生成一条状态记录，仅含外键、读取标记和时间戳，体积极小；
- UNIQUE KEY uk_user_notif 是核心约束，防止同一用户被重复关联同一条通知，保障数据一致性。
? 后台发送通知的正确流程（PHP 示例）
当管理员在后台发布一条新通知时，应执行 原子化两步操作：
<?php
// 使用 PDO + 事务确保数据一致性
try {
$pdo->beginTransaction();
// 步骤1：插入通知模板（单条记录）
$stmt = $pdo->prepare("INSERT INTO notifications (title, content) VALUES (?, ?)");
$stmt->execute(['系统维护提醒', '平台将于2024-06-15 02:00–04:00进行例行维护，请提前保存工作。']);
$notifId = $pdo->lastInsertId();
// 步骤2：批量插入所有活跃用户的状态记录（避免逐条循环！）
$users = $pdo->query("SELECT id FROM users WHERE status = 'active'")->fetchAll(PDO::FETCH_COLUMN);
if (!empty($users)) {
$placeholders = str_repeat('(?, ?, 0, NULL, NOW()),', count($users) - 1) . '(?, ?, 0, NULL, NOW())';
$stmt = $pdo->prepare("INSERT INTO user_notifications (notification_id, user_id, is_read, read_at, created_at) VALUES $placeholders");
$params = [];
foreach ($users as $uid) {
$params[] = $notifId;
$params[] = $uid;
}
$stmt->execute($params);
}
$pdo->commit();
echo "✅ 通知已成功推送给 " . count($users) . " 名用户。";
} catch (Exception $e) {
$pdo->rollback();
error_log('通知推送失败：' . $e->getMessage());
throw $e;
}⚠️ 注意事项：
- 严禁在应用层用 foreach 循环执行 N 次 INSERT——这会造成严重性能瓶颈；务必使用单条 INSERT ... VALUES (...), (...), (...) 批量写入；
- 始终包裹在事务中（如上例），确保“通知创建”与“用户关联”要么全部成功，要么全部回滚；
- 若用户量极大（如 >10 万），可考虑异步队列（如 Redis + Worker）分批处理，避免长事务阻塞；
- 为提升查询效率，建议在 user_notifications(user_id, is_read) 和 user_notifications(notification_id) 上建立复合索引。
? 用户端读取未读通知（高效查询示例）
-- 获取某用户（ID=123）的最新5条未读通知详情 SELECT n.id, n.title, n.content, n.created_at FROM user_notifications un JOIN notifications n ON un.notification_id = n.id WHERE un.user_id = 123 AND un.is_read = 0 AND n.is_active = 1 ORDER BY n.created_at DESC LIMIT 5; -- 标记某通知为已读（幂等安全） UPDATE user_notifications SET is_read = 1, read_at = NOW() WHERE user_id = 123 AND notification_id = 889 AND is_read = 0;
✅ 总结
该方案以最小冗余实现最大灵活性：
✔️ 单条通知内容永久只存一份，节省 99%+ 存储；
✔️ 支持任意粒度的推送（全员/指定角色/条件筛选用户）；
✔️ 已读状态完全隔离，互不影响；
✔️ 易于扩展（如增加“点击跳转链接”“优先级”字段只需修改 notifications 表）；
✔️ 兼容高并发写入，配合事务与批量操作保障强一致性。
从今天起，告别“为每个用户复制一条通知”的反模式——用清晰的关系建模，让通知系统既健壮又可持续演进。
