mysql不支持实时推送，需应用层实现；消息表须含status、trigger_type、reference_id等字段，用唯一索引防重复；未读数与最新通知查询需复合索引优化。
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 解决所有问题。