一般应用App都会有一个消息栏，展示消息列表，有系统通知消息，物流消息，活动消息等，且都有阅读状态。

基于这种需求，网上的站内信一般有三种方案：

1、一个表解决问题（用户量上百）：user_msg

id：自增id，title：消息标题，content：消息内容，logo：消息图片，user_id：用户id，is_read：阅读状态，is_delete：删除状态

create_at：创建时间，create_id：创建人，update_at：更新时间

2、两个表解决问题（用户量上万）

msg_info：消息表

id：自增id，title：消息标题，content：消息内容，logo：消息图片，create_at：创建时间，create_at：创建人

user_msg：用户消息表

id：自增id，user_id：用户id，msg_id：消息id，is_read：阅读状态，is_delete：删除状态，create_at：创建时间，update_at：更新   时间

这种方法也是在创建消息的时候同时会给要发的用户都创建一条消息，当用户量很大时，会出现数据库卡死的情况

3、3个表解决问题（用户量上百万）

msg_info：消息表

id：自增id，title：消息标题，content：消息内容，logo：消息图片，create_at：创建时间，create_at：创建人

user_type：发送群体（1全部用户 2部分用户），send_status：发送状态，send_at：发送时间

user_msg：用户消息表

id：自增id，user_id：用户id，msg_id：消息id，is_read：阅读状态，is_delete：删除状态，create_at：创建时间，update_at：更新

时间

当管理员选择部分用户时候，可以用到第三个表，消息用户关联表

msg_group：消息用户关联表

id：自增id，user_id：用户id，msg_id：消息id

这种方法看似跟第二种表结构一样，但是触发的时机是不同的，当管理员发送消息时，如果给所有用户发，则只创建消息表msg_info，

如果给部分用户发，则创建消息表msg_info和msg_group关联表。而用户消息表则在查看消息的时候去创建。这种方法麻烦的只是查询而已。

消息列表接口：

未读消息+已读消息

未读消息：select * from msg_info as a where a.id not in (select id from user_msg);默认给每一项都加上阅读状态和用户id

已读消息：select a.*,b.user_id,b.is_read from msg_info as a where b.is_delete=2 left join user_msg as b on a.id = b.msg_id;

删除消息接口：

删除未读消息时直接创建删除好的用户消息表，删除已读消息则直接更改删除状态

阅读消息接口：

阅读未读消息时直接创建已读状态的用户消息表

一般情况下阅读消息详情时要判断是否已读，未读的话就先调用阅读消息接口。消息详情接口则不用处理状态。