Question

我正在考虑发布的数据库模式及其评论，在社交网络应用程序的环境中，我正在徘徊，这两者中的哪一个会提供更好的性能：

我将帖子的评论存储在“评论”表格和“帖子”表中的帖子中。现在我对comments表的模式如下所示：

postId commentId postedBy Date CommentBody

由于为了检索帖子的评论，我需要搜索postId与此特定帖子的postId匹配的所有帖子，甚至我的postId也不能成为主键，因为postId在列中不是唯一的（因为对于单个帖子的几条评论），因此我在考虑是否可以将postId和commentId合并为一个单独的commentId （这将成为主键）使用哪个postId也可以被检索 。这就是我的想法：

CommentId将生成为postId * 100 + i（其中i是帖子的第i条评论）

因此，为了检索帖子的评论（比如postId = 8452），我会搜索所有带有commentId（这将是主键）的帖子，位于845200和825之间。 845299 ..而不是用postId = 8452搜索所有评论..（当然这将评论的最大数量限制为100）。但是这会导致任何性能上升吗？

Answer 1

这是你做的。加载具有代表性数据的数据库（例如）您希望它获得的大小的两倍。

然后运行您的查询并针对两个版本的模式测试它们。

然后，这是一个好位，每隔X周用新的最新数据重新测试一次，以确保情况没有改变。

这就是DBA的全部意义所在。除非您的数据永远不会改变，否则数据库优化不是一种“一劳永逸”的操作。唯一可以肯定的方法是在有代表性的条件下进行测试。

其他一切都是猜测。经过深思熟虑的猜测，不要误会我的意思，但我宁愿有一个确定性的答案，而不是任何人的猜测，特别是因为前者会适应变化。

我最喜欢的优化口号是“测量，不要猜！”

Answer 2

我建议：

在注释中使用带有复合键的双表结构，以获得最佳的索引单一性。
每篇文章100条评论是一个不好的限制，可能会在后面打你。
请勿使用不同的表格来评论视频/图片等。
如果有大量评论，请添加评论存档表并移动旧评论那里。大多数要求的评论（最新）将有一个更小，更有效的表格。
将Blob（图片和视频）保存在不同的分区而不是db中。在文件级别，Db会更小，碎片更少。

的问候， /吨

Answer 3

如果你要获得大音量，你应该制作一个表格帖子和表格评论以便有更小的表格:)。并且不要忘记在它们上使用索引和分区。

Answer 4

如果CommendId不唯一，您可以在PRIMARY KEY上创建合并(postId, CommentID)：

CREATE TABLE Comment
        (
        postId INT NOT NULL,
        commentId INT NOT NULL,
        …,
        PRIMARY KEY (postId, commentId)
        )

如果您的表格为MyISAM，则可以将commentId标记为AUTO_INCREMENT，这将为其分配每个帖子UNIQUE递增值。

如果它是唯一的，您可以在PRIMARY KEY上创建CommentId并在(PostId, CommentId)上创建二级索引：

CREATE TABLE Comment
        (
        commentId INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
        postId INT NOT NULL,
        …,
        KEY (postId, commentId)
        )

Answer 5

使用复合键。或者，如果您使用的是仅允许单列密钥的框架，则 postId 上的辅助索引

Answer 6

CommentId将生成为postId * 100 + i（其中i是对帖子的第i条评论）

因此，为了检索帖子的评论（比如使用postId = 8452），我会搜索所有带有commentId的帖子（这将是主键），位于845200和825之间。 845299 ..而不是用postId = 8452来搜索所有评论..（当然这会将评论的最大数量限制为100）。但这会导致任何性能上升吗？

这可能会比基于postId外键列的查询提供更多更差性能，但唯一可以确定的方法是尝试这两种技术（如paxdiablo所建议）并测量性能

哪个有更好的表现？

6 个答案: