MySQL 本身不支持实时推送，不能直接“推送通知”到客户端；它只能作为消息数据的持久化存储和状态管理后端。真正的推送必须由应用层（如 WebSocket 服务、APNs/FCM 网关）或定时轮询机制来完成。
如何设计消息表结构与状态字段
消息不是发完就丢，需要可追溯、可重试、可标记已读。核心字段不能只存
content和
user_id，必须包含生命周期控制信息：
status：枚举值如
'pending'（待下发）、
'sent'（已触达推送服务）、
'read'（用户点开）、
'failed'（推送失败）
trigger_type：标识来源，如
'comment'、
'like'、
'system'，便于前端分类展示或静默处理
reference_id：关联业务主键（如
post_id或
comment_id），点击通知时跳转用
created_at+
updated_at：必须有，尤其
updated_at要在状态变更时更新，避免误判超时 避免用
is_read TINYINT(1)这类布尔字段——扩展性差，无法表达“已送达但未打开”等中间态
怎么避免重复插入和漏发消息
高并发下用户可能被多次触发同类型通知（比如连续点赞同一内容）。靠应用层去重不可靠，应在数据库加约束：
对「用户 + 事件类型 + 关联对象」组合建唯一索引，例如：ALTER TABLE notifications ADD UNIQUE KEY uk_user_event_ref (user_id, trigger_type, reference_id);插入时用
INSERT IGNORE或
ON DUPLICATE KEY UPDATE status = VALUES(status), updated_at = NOW()，防止冗余记录 不要依赖应用层“查一遍再插”，竞态条件必然导致重复；也不要全靠定时任务扫全表补发——量大时 I/O 压力陡增 若需支持“仅最近一条有效”逻辑（如“你有新粉丝”，不累计），可在
ON DUPLICATE KEY UPDATE中把旧记录
status设为
'superseded'
如何高效查询未读数与最新几条通知
首页右上角小红点、下拉通知列表，这两个查询最频繁，必须走索引且避免
SELECT *： 未读数统计：用覆盖索引加速
SELECT COUNT(*) FROM notifications WHERE user_id = 123 AND status = 'pending' OR status = 'sent';
确保有复合索引：
INDEX idx_user_status (user_id, status)查最新 20 条：按
created_at DESC排序，但注意
status过滤条件必须进索引，否则会全表扫描
SELECT id, content, trigger_type, reference_id, created_at FROM notifications WHERE user_id = 123 AND status IN ('pending', 'sent', 'read') ORDER BY created_at DESC LIMIT 20;推荐索引：
INDEX idx_user_status_time (user_id, status, created_at)别在查询里用
JSON_EXTRACT解析字段做过滤——这会让索引失效；业务字段该拆就拆成独立列
真正难的不是存和查，而是状态同步：MySQL 里的
status = 'sent'只代表“已交到推送网关”，不代表设备收到了；而
'read'通常要靠客户端上报回执。这两步之间存在天然延迟和失败可能，得靠异步补偿任务兜底，而不是指望一条 SQL 解决所有问题。
