哪个有更好的表现？

Question

我正在考虑在社交网络应用程序的上下文中发布及其评论的数据库模式，并且徘徊在这两者中的哪一个会带来更好的性能：

我在“评论”表中存储帖子的评论 ，在“帖子”表中存储帖子 。 现在，我的注释表架构如下所示：

postId commentId postedBy日期CommentBody

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

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

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

Answer 1

这就是你要做的。 用（例如）两倍于您期望的大小加载具有代表性数据的数据库。

然后运行查询，并针对两个版本的架构对其进行测试。

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

这就是成为DBA的全部目的。 除非您的数据永远不会改变，否则数据库优化不是“一劳永逸”的操作。 并且唯一可以确保的方法是在代表性条件下进行测试。

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

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

Answer 2

我建议：

• 在注释中使用带有复合键的两表结构，以获得索引的最佳唯一性。

• 每篇文章100条评论是一个不好的限制，可能会打倒您。

• 请勿使用其他表格来评论视频/图片等。

• 如果有大量注释，请添加一个注释存档表并将旧注释移到该表中。 要求最多的评论（最新）将有一个更小，更有效的表格。

• 不要将Blob（图片和视频）保存在其他分区上，而不是保存在db中。 在文件级别，Db会更小且碎片更少。

/ t

Answer 3

如果您要获得更大的体积，则应创建一个表Post和一个表Comment，以使表更小:)。 并且不要忘记在它们上使用索引和分区。

Answer 4

如果CommendId不是唯一的，则可以在(postId, CommentID)上创建一个复合PRIMARY KEY ：

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

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

如果它是唯一的，则可以在CommentId上创建一个PRIMARY KEY ，并在(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和845299 ..之间，而不是搜索所有具有postId = 8452 ..（当然这会将评论的最大数量限制为100）。 但这会导致性能提升吗？

与基于postId外键列的查询相比，这可能会带来更差的性能，但是确保的唯一方法是尝试两种技术（如paxdiablo所建议）并测量性能。