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