各位CSDNer好！
现有如下问题向大家请教：1、设计一个消息中心，存储两种消息
1）、一个用户对另一个用户的消息（单发）
2）、系统对每个用户下发的消息（群发）2、对于消息存在三种状态：新消息-0、已获得但未查看详细-1、已查看详细-2
1）、当用户进行获得消息操作时，消息状态由0变为1
2）、当用户进行查看详细操作时，消息状态由1变为23、当一个用户上线后，知道有新消息时，会进行获得消息操作，此时如果该用户的
消息大于10条时会返回消息的排序为 最新的、最近的。
=============================================================针对以上需求，目前设计的表结构主要字段如下：
1）、message_info_t表部分字段（存储记录表）
msg_id(消息ID)
send_to(如果为空代表群发、如果不为空则为指定的另一个用户的ID)
send_flag(对于单条消息（为上面的三种状态之一），如果是群发消息则始终为0)
end_time(有效期)
2）、message_get_t表（存储群发消息状态表）
msg_id(群发消息ID)
send_to(发送到的手机号)
send_flag（为1或2）
表结构设计思路如下：
1）、所有的消息无论是单发的还是群发都放在message_info_t表中，用send_to字段加以区别，这样不会一次群发产生太多的消息。
2）、对于查看的群发消息我们将查看过的消息ID记录到message_get_t表，并设置状态位。3）、用户想要获得新的和未查看详细的消息两种消息则需要两个表关联查询，即查询的消息是（message_info_t表中send_to不为空的且状态位为0或1的）OR（message_info_t表中send_to为空且message_get_t表中send_flag为2或message_get_t表中没有记录的）,而且要按照消息的状态为第一条件进行排序，也就是新的消息放在前面，而都是新消息则把最近的消息放在前面 =============================================================问题如下：
1、这样设计的表结构是否合理？？大家提供一些新的思路
2、对于这种需求，每一次查询都要进行全表扫描，那么是否加表分区（消息会越来越多）？？加什么样的表分区？？索引建成什么样的？？
3、最主要的问题：
目前的实现方式，存在这样一个BUG，就是由于上面的群发消息在message_info_t表中，始终是0状态，永远是新的，这样在关联查询的时候排序，如果关联查询满足条件的前10条，那么在查询后，即使在message_get_t表中记录了已经查看，并设置为状态为1，但是原表中状态没有变，用户在查下一个十条的时候，这些已经查看的群发消息还会再次查询出来，而不是真正的下一个十条。，如何才能使message_get_t表中的状态代替message_info_t表中查询出来的群发消息的状态？？
=============================================================对于上面的问题，特别是第3个问题，大家多多提建议！！谢谢！
现有如下问题向大家请教：1、设计一个消息中心，存储两种消息
1）、一个用户对另一个用户的消息（单发）
2）、系统对每个用户下发的消息（群发）2、对于消息存在三种状态：新消息-0、已获得但未查看详细-1、已查看详细-2
1）、当用户进行获得消息操作时，消息状态由0变为1
2）、当用户进行查看详细操作时，消息状态由1变为23、当一个用户上线后，知道有新消息时，会进行获得消息操作，此时如果该用户的
消息大于10条时会返回消息的排序为 最新的、最近的。
=============================================================针对以上需求，目前设计的表结构主要字段如下：
1）、message_info_t表部分字段（存储记录表）
msg_id(消息ID)
send_to(如果为空代表群发、如果不为空则为指定的另一个用户的ID)
send_flag(对于单条消息（为上面的三种状态之一），如果是群发消息则始终为0)
end_time(有效期)
2）、message_get_t表（存储群发消息状态表）
msg_id(群发消息ID)
send_to(发送到的手机号)
send_flag（为1或2）
表结构设计思路如下：
1）、所有的消息无论是单发的还是群发都放在message_info_t表中，用send_to字段加以区别，这样不会一次群发产生太多的消息。
2）、对于查看的群发消息我们将查看过的消息ID记录到message_get_t表，并设置状态位。3）、用户想要获得新的和未查看详细的消息两种消息则需要两个表关联查询，即查询的消息是（message_info_t表中send_to不为空的且状态位为0或1的）OR（message_info_t表中send_to为空且message_get_t表中send_flag为2或message_get_t表中没有记录的）,而且要按照消息的状态为第一条件进行排序，也就是新的消息放在前面，而都是新消息则把最近的消息放在前面 =============================================================问题如下：
1、这样设计的表结构是否合理？？大家提供一些新的思路
2、对于这种需求，每一次查询都要进行全表扫描，那么是否加表分区（消息会越来越多）？？加什么样的表分区？？索引建成什么样的？？
3、最主要的问题：
目前的实现方式，存在这样一个BUG，就是由于上面的群发消息在message_info_t表中，始终是0状态，永远是新的，这样在关联查询的时候排序，如果关联查询满足条件的前10条，那么在查询后，即使在message_get_t表中记录了已经查看，并设置为状态为1，但是原表中状态没有变，用户在查下一个十条的时候，这些已经查看的群发消息还会再次查询出来，而不是真正的下一个十条。，如何才能使message_get_t表中的状态代替message_info_t表中查询出来的群发消息的状态？？
=============================================================对于上面的问题，特别是第3个问题，大家多多提建议！！谢谢！
2:按照消息的状态为第一条件进行排序，也就是新的消息放在前面，而都是新消息则把最近的消息放在前面,在message_info_t表部分字段（存储记录表） 里加上消息创建日期,作为索引
1、“始终没有出现用户和消息ID关联的表,,,,,,如何知道用户查看了消息?”
用户与消息就是用send_to字段关联的，如果不为空则代表发给某个用户有，如果为空则发给所有用户
用户在发送任何一次请求的时候都会看一下是否有新的消息，有则会在客户端面给用户提示，接下来用户
可以分别进行查看数据操作与查看详细操作来完成对消息的访问。2、“加上消息创建日期,作为索引”，这个已经加了。
消息实体表(消息ID,消息内容,创建日期),
用户消息关系表(用户手机,消息ID,短信状态,短信类型......)
规范是这样做的,都是要结合你的业务来
消息实体表(消息ID,消息内容,创建日期,短信类型),
用户消息关系表(用户手机,消息ID,短信状态,......)
这样