应使用 TIMESTAMP 类型并建立 (user_id, is_read, created_at) 复合索引支撑高并发未读消息查询，避免单列索引失效、全表扫描及时区不一致问题。
用 TIMESTAMP + 复合索引支撑高并发消息查询
用户拉取“最新未读消息”是高频操作，created_at 和 is_read 必须联合走索引，否则分页一卡就是几秒。别只给 created_at 加单列索引——MySQL 优化器在 WHERE is_read = 0 ORDER BY created_at DESC 场景下大概率不走索引。
- 建表时直接加复合索引：
ALTER TABLE notification ADD INDEX idx_user_read_time (user_id, is_read, created_at) -
user_id必须放最左，因为所有查询都带接收者 ID；is_read放第二位，能快速过滤未读；created_at放最后，满足排序需求 - 避免在
content字段上建索引——TEXT/VARCHAR(2048) 全字段索引会拖慢写入，真要搜内容用全文索引或外部 搜索引擎
不要用触发器实时发 MQ，改用 Canal + binlog 做变更捕获
在 AFTER INSERT 触发器里调 RabbitMQ 或 Kafka 生产者，看似简单，实则埋雷：事务提交前就发消息，数据库回滚了而 MQ 消息已发出，数据必然不一致；且触发器逻辑阻塞主库写入，QPS 上千就抖动。
- 必须开启 MySQL
binlog-format=ROW和log-bin，并设置唯一server_id - 用
Canal订阅 binlog，它把每条 INSERT 解析成结构化事件，再由你自己的消费者投递到 MQ —— 这样消息发出时机在事务提交后，天然保序、可重试 - 注意 Canal 的
destination配置要和表名严格匹配，否则漏事件；测试阶段务必开canal.instance.filter.regex白名单，避免误吞系统表
消息状态更新别 update 全字段，用 WHERE 条件锁最小粒度
用户点“全部已读”，后端 执行 UPDATE notification SET is_read = 1 WHERE user_id = ? AND is_read = 0 是常规操作，但容易忽略两个坑：没加 created_at 条件，导致扫全表；没限制影响行数，一次误操作清空百万用户未读态。
- 加
LIMIT 10000是底线，哪怕业务允许分批处理 ——UPDATE …… LIMIT能避免长事务锁表 - 如果要做“已读回溯”（比如用户撤回已读），别靠
updated_at判断，要在表里加read_at字段存首次标记时间，否则ON UPDATE CURRENT_TIMESTAMP会覆盖原始创建时间 -
is_read字段用TINYINT(1)而非BOOLEAN，后者在某些 MySQL 版本里是TINYINT别名，但 ORM 映射可能出歧义
客户端轮询太傻，但 WebSocket 接入别绕过 MySQL 直连
前端 用 setInterval 每 5 秒查一次新消息，服务器压力大、延迟高、电量耗得快；换成 WebSocket 看似先进，但如果每个连接都直连 MySQL 执行 SELECT …… WHERE user_id = ? AND created_at > ?，连接数一过千，MySQL 的 max_connections 就爆了。
- WebSocket 服务层必须做连接复用和状态缓存：内存里记每个用户的
last_fetched_at，只推增量，不查库 - 真正需要查库的场景（如历史消息翻页），走单独的 HTTP 接口，用前面说的复合索引，别混进长连接逻辑
- 别信“MySQL 8.0 原生支持 WebSocket”这种说法——它压根不支持，所谓“支持”只是某些云厂商封装的代理层，底层仍是轮询或 CDC
最易被忽略的一点：created_at 和 updated_at 必须用 TIMESTAMP 而非 DATETIME，否则跨时区部署时，用户看到的“2 分钟前”可能是服务器本地时间，不是用户手机所在时区——而 TIMESTAMP 自动转时区，NOW() 写入的就是 UTC，展示时再转本地，才真正一致。
