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