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真要分表，等慢查询明显增多、且归档无效时，再按
user_id % N或时间范围拆 别一上来就搞分库分表，99% 的项目根本用不上
实际最难的从来不是建表，而是「通知是否真的触达了用户」——
notification表只是起点，后面还得配
notification_log记推送结果、
notification_setting控制免打扰，这些才是线上出问题时最先被翻出来的表。
