应设计notification主表，含BIGINT id、receiver_id、可选sender_id、TINYINT type、VARCHAR(2048) content、JSON extra_data、TINYINT is_read及TIMESTAMP created_at/updated_at；建receiver_id、is_read单列索引和(receiver_id,is_read,created_at)联合索引；按需扩展setting与log辅助表；优先用TIMESTAMP存时间。
实现一个稳定高效的消息通知系统，MySQL 表结构设计是基础。关键不是字段堆得多，而是围绕“查得快、标得准、扩得开”三个目标来组织。
核心表字段怎么选
一张主表（如 notification）应包含以下必要字段：
- id：BIGINT 自增主键，避免 INT 溢出，支撑千万级消息量；
- receiver_id：接收用户 ID，必须为 BIGINT（兼容不同用户体系，如微信 OpenID、内部 UID）；
- sender_id（可选）：私信或互动类场景需记录来源，设为 NULLABLE；
- type：TINYINT 枚举，比如 1=系统公告、2=评论提醒、3=点赞、4=订单状态，方便 WHERE type IN (2,3) 快速过滤；
- content：VARCHAR(2048) 足够承载大多数通知文本；若需富文本或附件链接，可额外加 extra_data JSON 字段（MySQL 5.7+ 支持）；
- is_read：TINYINT(1)，0=未读，1=已读，支持 COUNT(*) WHERE is_read = 0 统计未读数；
- created_at：TIMESTAMP DEFAULT CURRENT_TIMESTAMP，自动记录生成时间，时区友好、节省空间；
- updated_at：TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，用于追踪状态变更（如标记已读时间）。
索引不能只建 user_id
单靠 receiver_id 索引远远不够。真实查询多是“查某人未读消息，按时间倒序取最新 20 条”。推荐三类索引组合：
- 单列索引：receiver_id（高频筛选入口）；
- 单列索引：is_read（尤其当需全站未读统计或后台批量清理过期通知时）；
- 联合索引：(receiver_id, is_read, created_at) —— 覆盖查询，避免回表，让 ORDER BY created_at DESC + LIMIT 20 真正飞起来。
如果按类型查也频繁（如 App 首页只展示“互动类”通知），可追加 (receiver_id, type, created_at) 索引。
要不要拆辅助表
初期单表足够，但业务变复杂后建议分层扩展：
- notification_setting：字段含 user_id、type、is_enabled（是否推送短信/站内信/微信）、mute_until（免打扰截止时间），解决“用户不想收某类通知”的需求；
- notification_log：记录每条通知的推送动作（device_token、push_time、status=success/failed），用于补发与故障排查；
- 不建议一上来就分库分表。等单表超 500 万行、慢查询明显增多时，再按 receiver_id % N 或按月分表更稳妥。
时间字段用 TIMESTAMP 还是 DATETIME
优先选 TIMESTAMP：
- 占 4 字节（DATETIME 占 8 字节），对海量消息更省存储；
- 自动时区转换：写入时按应用服务器时区转为 UTC 存储，读取时再转回本地时区，用户看到的时间始终一致；
- 注意上限：2038 年前有效，若系统需长期运行（如政务系统），可改用 DATETIME(3)（毫秒精度）并自行处理时区逻辑。
