聊天应用单次HTTP请求执行多轮SQL操作是否合理？

你的当前实现存在明显的性能冗余与设计复杂度问题，不算良好实践，具体问题和优化方向如下：

核心问题 #

1. 多DB请求的性能瓶颈：单条消息触发3-4次甚至更多数据库操作，在高并发场景下会显著增加接口延迟，同时占用更多数据库连接资源，极易成为系统性能短板。
2. 消息副本的冗余与一致性风险：为每个用户存储消息副本会造成大量数据重复，浪费存储资源；后续若需修改消息（如撤回、编辑），还要同步更新所有副本，极易出现数据不一致的情况。
3. Chat Room设计逻辑复杂：“每位用户拥有独立Chat Room”的设计，会让“判断双方是否存在共同Room”的逻辑变得繁琐，额外增加查询成本，也不符合常规聊天应用的Room模型设计思路。

优化方案 #

1. 调整数据库模型（核心优化） #

参考主流聊天应用的设计思路，重构模型：

• 单Chat Room对应对话主体：一个Chat Room对应一组对话用户（一对一或多人群聊），通过中间关联表RoomUser绑定参与用户，而非为每个用户创建独立Room。
• 消息表仅存单条记录：取消消息副本逻辑，每条消息仅存一条，通过chat_room_id关联到对应Room。如果需要实现“已读/未读”“用户独立删除消息”这类需求，单独创建MessageUserStatus表，记录每个用户对每条消息的状态（已读标记、软删除标记等），而非复制消息内容。

2. 简化发送消息流程 #

优化后单条消息的操作可压缩至2-3次DB请求（结合数据库特性还能进一步减少）：

• 用UPSERT完成Room的创建/查询：借助数据库原生UPSERT语法（如MySQL的INSERT ... ON DUPLICATE KEY UPDATE、PostgreSQL的INSERT ... ON CONFLICT），一次操作完成“查询是否存在Room-不存在则创建”的逻辑，替代原来的“查询+插入”两次操作。
• 插入单条消息记录：仅插入一条消息到Chat表，关联对应的Chat Room。
• 事务内完成Room更新：将消息插入与Room最后消息更新放在同一个数据库事务中，保证操作原子性；也可通过数据库触发器自动更新Room的last_message_id或last_message_time，减少应用层操作。

3. 特殊需求的折中方案 #

如果你的设计是为了实现“用户可独立删除自己的消息视图”这类特殊需求，也可以优化现有逻辑：

• 用软删除标记替代物理副本：消息仅存一条，为每个用户添加“是否删除该消息”的标记字段，而非复制整条消息。
• 批量操作减少请求数：将“创建两个消息副本+更新Room”合并为批量插入+单次更新，通过数据库批量写入语法减少请求次数。

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