用 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，展示时再转本地，才真正一致。
