lounah Asked:2020-08-22 02:43:00 +0000 UTC2020-08-22 02:43:00 +0000 UTC 2020-08-22 02:43:00 +0000 UTC MySQL数据库存储优化 772 你好。MySQL 中有一张表，用于存储用户消息。(_id, from_id, to_id, 日期, 内容 ) 来自所有通信的所有消息都将存储在该表中。我明白这是完全不合理和错误的，因为从服务器下载信件是通过一个简单的 SELECT by from_id 并按日期排序来实现的。那么，如何合理地建表存储用户对应关系，使得数据库查询不至于消息量过大而过长呢？ mysql 1 个回答 Voted Best Answer A K 2020-08-22T14:07:22Z2020-08-22T14:07:22Z 如果您的任务是以树状评论的形式显示用户消息，那么您将有机会使用数据库中的三种存储方法之一：通常的 Adjacency List、Nested Set 或 Materialized Path。这个主题在网上有很多介绍，例如：https ://habrahabr.ru/post/46659/ 所以你真的不会想到一个不同的数据库结构，Mike 说得对。 我过去一直在修补流行的论坛引擎，许多都对私人消息框的大小有限制——比如，每个人都是 50。我怀疑这些限制只是为了将服务器负载保持在适当的限制内论坛。 尽管在这里我几乎感觉不到，尽管数据库已经膨胀了好几年了：尽管如此，通过 to_id （对于传入消息）或 from_id （对于已发送消息）进行选择非常有效地切断了很多线程。
如果您的任务是以树状评论的形式显示用户消息，那么您将有机会使用数据库中的三种存储方法之一：通常的 Adjacency List、Nested Set 或 Materialized Path。这个主题在网上有很多介绍，例如：https ://habrahabr.ru/post/46659/
所以你真的不会想到一个不同的数据库结构，Mike 说得对。
我过去一直在修补流行的论坛引擎，许多都对私人消息框的大小有限制——比如，每个人都是 50。我怀疑这些限制只是为了将服务器负载保持在适当的限制内论坛。
尽管在这里我几乎感觉不到，尽管数据库已经膨胀了好几年了：尽管如此，通过 to_id （对于传入消息）或 from_id （对于已发送消息）进行选择非常有效地切断了很多线程。