我有一个网站，其中的成员互相发送消息。会有一些成员，他们喜欢发送消息 - 我相信你可以看到这是怎么回事。
目前我已经说过消息存储在一个很好的关系表中，巧妙地命名为“消息”，具有不同的状态 ID 来表示，呃，状态（未读，已保存等）。我知道这是事后的事，但我认为我真的需要将此表拆分为其他几个表（例如，每种状态类型不止一个）而且我不确定最好的方法是什么关于它。
我有几个想法，但都不是火箭科学，但我很好奇这是否有“标准解决方案”。谷歌不建议这样做，但我想这些问题在像 stackoverflow 这样的地方之外并不常见。
有人已经做过了吗？
我肯定会将“消息”表拆分为多个。例如：
消息状态消息消息文本
这样，如果您在某人的收件箱中显示项目列表，您只需要扫描“消息”表，该表是较小且固定长度的列，以获得最大搜索速度。当有人想打开并查看消息正文时，您可以点击“MessageText”表。“消息状态”只是一个查找表，用于将 tinyint FK 加入“消息”表。
与可能带有 mediumtext 列的 1 个表相比，您将获得更多的性能。
你有没有想过可能有一个归档过程来归档任何早于一段时间的东西？
通过适当的索引和微调，您将不得不有相当多的消息需要在多个表中移动它们，除非它是空间问题。
拥有包含大量数据的消息表没有任何问题。如果你真的不需要它，没有理由拆分它。
如果您担心此表的性能，请首先根据您的需要明智地选择存储引擎：我的建议是使用 InnoDB，因为它是写密集型的。然后查看索引以加快读取速度。
如果表真的变得太大而且太慢，你可以做的是创建 2 个表：
带有 MyISAM 存储的 messages_archive 表（仅用于快速检索和搜索“归档”消息）。
带有 InnoDB 存储的 messages_inbox 表：这是经常插入新消息的表。
选修的 ：
顺便说一句，这不是您所说的“标准解决方案”，只是一个想法。:)
编辑 ：
从您的评论中，我了解到您正在寻找的实际上是“分区”。
不同的 MySQL 分区类型允许您按范围、列表、键或散列物理隔离数据。