notification表需支持泛化引用和结构化存储：ref_type与ref_id替代外键，content用JSON格式，link字段必备，expires_at用于清理过期数据。
notification 表不是日志表，不能只存“谁发了什么”，否则查未读数、做推送补发、支持跳转都会卡死。
字段设计：别漏掉 ref_type 和 ref_id，也别硬外键
用户收到一条「订单 #123 已发货」通知，业务订单表将来可能被物理删除，但这条通知得长期保留——所以不能用 FOREIGN KEY (order_id) REFERENCES orders(id)。正确做法是用泛化引用：
-
ref_type VARCHAR(32)存"order"、"article"等类型标识 -
ref_id BIGINT存对应记录 ID（如 123），允许为 NULL -
content推荐用 JSON 格式，比如{"order_no": "ORD20260129001", "status": "shipped"}，比纯文本更易解析和国际化 -
link字段必须有，值如"/orders/123"，前端点击直接跳转，别指望客户端拼 URL -
expires_at建议加上，避免垃圾数据堆积；后台可定时DELETE FROM notification WHERE expires_at
索引怎么建：idx_user_read_created 是命脉
高频查询就两个：SELECT COUNT(*) FROM notification WHERE user_id = 123 AND is_read = 0 和 SELECT * FROM notification WHERE user_id = 123 AND is_read = 0 ORDER BY created_at DESC LIMIT 20。没对路的索引，百万行后秒变慢 SQL。
- 必须建联合索引：
ALTER TABLE notification ADD INDEX idx_user_read_created (user_id, is_read, created_at); - 别单独给
is_read建索引——区分度太低（95% 是 0），MySQL 优化器大概率 ignore - 别漏
user_id，它是所有查询的绝对前置条件，没它索引等于白建 - 如果还要按类型筛选（比如 App 首页只展示互动类），再加一个
(user_id, type, created_at)索引
防重复插入：用唯一约束比应用层判重更稳
支付回调重试、消息队列重复投递，都可能导致同一条通知发三次。靠代码里先 SELECT 再 INSERT？并发一高就失效。
- 加唯一约束：
UNIQUE KEY uk_user_type_ref (user_id, type, ref_id) - 插入时用
INSERT IGNORE或ON DUPLICATE KEY UPDATE is_read = VALUES(is_read)，不中断流程 - 注意前提：业务上允许「同一用户对同一业务实体只收一条同类通知」——绝大多数场景成立（你不会想看到 5 条「你的订单 #123 已发货」）
- 如果逻辑更复杂（如「7 天内只推一次优惠券」），就得上 Redis：
SET user:123:type:coupon:seen 1 EX 604800
什么时候分表？500 万行前别动
单表撑到 500 万行以内，只要索引合理、归档策略到位，完全不用分表。过早分表只会增加维护成本和查询复杂度。
- 优先按月归档：
CREATE TABLE notification_202601 LIKE notification;+INSERT INTO notification_202601 SELECT * FROM notification WHERE created_at < '2026-02-01'; - 真要分表，等慢查询明显增多、且归档无效时，再按
user_id % N或时间范围拆 - 别一上来就搞分库分表，99% 的项目根本用不上
实际最难的从来不是建表，而是「通知是否真的触达了用户」——notification 表只是起点，后面还得配 notification_log 记推送结果、notification_setting 控制免打扰，这些才是线上出问题时最先被翻出来的表。
