消息应用MySQL可扩展数据库设计：未读消息追踪方案咨询

云原生阿岚

2026-5-21

针对你提出的未读消息追踪问题，新增unread_conversations表确实是一个可行的方案，但我也会给你分析这个方案的利弊，以及另一种常见的替代思路，帮你做更合适的选择。

方案一：新增`unread_conversations`表

优势

逻辑简单直观：每次发送消息时，给对话内除了发送者之外的所有关联用户插入（或更新）一条未读记录；用户打开对话时，删除该用户对应的这条记录。查询未读对话数量或列表时，直接从这个表关联查询即可，开发成本低。
性能表现优秀：如果只需要快速获取用户的未读对话数，直接执行COUNT(*) FROM unread_conversations WHERE user_id = ?就能得到结果，不需要去消息表做复杂的时间范围聚合查询，尤其适合高并发场景。

需要注意的细节

避免数据冗余：一定要给user_id和conversation_id添加唯一约束（比如UNIQUE KEY (user_id, conversation_id)），这样同一用户同一对话只会存在一条未读记录。新消息到来时，用INSERT ... ON DUPLICATE KEY UPDATE更新记录的时间戳即可，不用重复插入。
处理并发场景：比如多个用户同时给同一个对话发消息，唯一约束能防止重复插入未读记录，保证数据一致性。
清理过期数据：用户打开对话后，要及时删除对应的未读记录，避免表数据无限膨胀。

方案二：用`last_read_at`字段追踪（无额外表）

如果不想新增表，另一种主流方案是在用户与对话的关联表（如果现有设计里没有，建议新增user_conversations关联表）中添加last_read_at字段：

实现逻辑

当用户发送消息时，更新对应对话的updated_at时间戳；
当用户打开对话时，将该用户在user_conversations中的last_read_at设置为当前时间；
查询未读状态时，对比对话的updated_at和用户的last_read_at：如果updated_at > last_read_at，说明该对话有未读消息；统计未读消息数时，查询对应对话中created_at > last_read_at的消息数量。

优势

架构简洁：无需新增表，数据结构更紧凑，避免额外的数据库维护成本。
减少写操作：发消息时只需要更新对话的updated_at，不用给每个关联用户插入未读记录，降低数据库写压力。

潜在问题

性能瓶颈：如果对话内消息量极大，每次统计未读消息数都要做范围查询，可能会拖慢查询速度。这种情况下可以结合缓存（比如Redis）存储用户的未读消息数，定期从数据库同步，或者在用户打开对话时预计算并缓存。

方案选择建议

如果你的应用处于初期阶段，用户量和消息量都不大，优先考虑last_read_at方案，架构更简单，后期优化空间也大；
如果你的应用需要高并发下快速返回未读数据，或者已经预见消息量会快速增长，那unread_conversations表的方案会更稳妥，能避免后期复杂的性能优化工作。

如果最终选择新增unread_conversations表，参考表结构可以是：

CREATE TABLE unread_conversations (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT NOT NULL,
    conversation_id INT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    -- 唯一约束防止重复记录
    UNIQUE KEY idx_user_conversation (user_id, conversation_id),
    -- 外键关联用户和对话表
    FOREIGN KEY (user_id) REFERENCES users(id),
    FOREIGN KEY (conversation_id) REFERENCES conversations(id)
);

内容的提问来源于stack exchange，提问作者Walker