规范化是否真的损害了高流量网站的性能？

Question

我正在设计一个数据库，我想规范化数据库。在一个查询中，我将加入大约30-40张表格。如果它变得非常流行，这会不会损害网站的性能？这将是主要的查询，并且将被调用50％的时间。其他查询我将加入两张表格。

我现在可以选择正常化或不正常化，但如果规范化在未来成为问题，我可能不得不重写软件的40％，这可能需要很长时间。在这种情况下，正常化是否真的受伤？我应该在现在有空的时候反规范化吗？

Answer 1

我引述如下： “正常化的正确性，反规范化的速度 - 并且只在必要时”

我是指你：In terms of databases, is "Normalize for correctness, denormalize for performance" a right mantra?

HTH。

Answer 2

不要进行早期优化。非规范化不是加速网站的唯一途径。你的缓存策略也是非常重要的，如果30-40表的查询是相当静态的数据，缓存结果可能证明是一个更好的优化。

另外，考虑到读取次数的写入次数。如果您为每次插入或更新执行大约10次读取，则可以说数据相当静态，因此您应该将其缓存一段时间。

如果最终使您的模式非规范化，您的写入操作也将变得更加昂贵，并且可能会让速度变慢。

在进行太多优化之前真正分析您的问题，并等待查看系统瓶颈的位置，因为您可能最终会惊讶于您应该首先优化哪些内容。

Answer 3

当性能是一个问题，还有比非规范化通常是更好的选择：

• 创建的相关表相应的索引和统计
• 缓存
• 物化视图（MS SQL Server中索引视图）
• 除了在大多数情况下使用的规范化表格（需要编写同步代码，它可以作为三元组运行）之外，还有一个表格的非规范化副本（专用于需要它们的查询） gger或预定作业，具体取决于您需要的数据精度）

Answer 4

标准化可能会损害性能。然而，这并不是过早反规范化的理由。

从完全标准化开始，然后您会看到是否有任何性能问题。按照你所描述的速度（每天1000次更新/插入），我认为除非桌子很大，否则你不会遇到问题。

即使有大量您可以使用的数据库优化选项（索引，准备存储过程，物化视图，...）。

Answer 5

也许我在这里错过了一些东西。但是如果你的架构要求你在一个查询中加入30到40个表格，那么这个查询就是你网站的主要用途，那么你就有更大的问题。

我同意他人，不要过早地优化您的网站。但是，您应该优化体系结构以解释您的主要用例。对于运行时间超过50％的查询，40个表连接未优化IMO。