我试图坚持保持数据库规范化的做法，但这导致需要运行多个连接查询。如果许多查询使用连接而不是调用可能包含冗余数据的单个表，会导致性能下降吗？
答案 0 :(得分：20)
保持数据库规范化直到你发现了瓶颈。然后，只有在仔细分析后才能进行反规范化。
在大多数情况下，拥有良好的索引和最新统计数据将解决大多数性能和阻塞问题，而不会出现任何非规范化。
如果存在写入以及对其进行读取，则使用单个表可能会导致性能下降。
答案 1 :(得分：16)
那可能是在RDBMS出现之前，但我认为他已经扩展了规则以包含它们。
标准化数据模型几乎总是需要多表SELECT;正如这种问题经常出现的那样，对“非规范化”的“正确”答案是什么？问题取决于几个因素。
DBMS平台。
多表与单表查询的相对性能受应用程序所在平台的影响：查询优化程序的复杂程度可能会有所不同。例如，根据我的经验，MySQL在单表查询上的速度非常快，但并不能优化具有多个连接的查询。对于较小的表（比如说不到10K行），这不是一个真正的问题，但是对于大型（10M +）表来说真的很痛。
数据量
除非您正在查看100K +行区域中的表，否则几乎不应该是一个问题。如果您正在查看数百行的表格大小，我甚至不会考虑索引。
（缩小）归一化
规范化的重点是尽量减少重复，以确保只需在一个地方更改必须更新的任何字段值。非规范化打破了这一点，如果对重复数据的更新很少（理想情况下它们永远不会发生），这就不是什么大问题了。因此，在复制除最静态数据之外的任何内容之前要仔细考虑，注意您的数据库可能会显着增长
要求/约束
您想要满足哪些性能要求？你有固定的硬件或预算吗？有时，通过硬件升级可以最轻松地实现性能提升 - 甚至是最便宜的。您期望什么交易量？小企业会计系统与Twitter有着截然不同的形象。
最后一个想法让我感到震惊：如果你足够不规范，你的数据库与平面文件有什么不同？ SQL对于灵活的数据和多维的retieval而言是极好的，但它可能比直接顺序或相当简单的索引文件慢一个数量级（至少）。
答案 2 :(得分：4)
性能差异？
理智差异。
答案 3 :(得分：2)
我们将查询优化保留到数据库，原因与我们将代码优化保留到编译器的原因相同。
如今，大多数现代RDBMS在这方面都相当不错。
在您认为在某些情况下非正规化是“正常”之前，请考虑一下：通常您对每个属性都不感兴趣。因此，从磁盘上加载不需要的数据效率很低（通常是数据库中效率最低的组件）。如果你有一个非规范化设计，连续存在大量冗余数据，这可能会更糟。如果你必须更新所有冗余数据，那就更糟了。加载一些只包含感兴趣列的窄表并加入它们会更有效。同样，这取决于数据库，因此如果没有分析，你就没有任何线索。
如果您真的担心性能问题，那么您可能会谈论可伸缩性问题。在这种情况下，您可能需要查看sharding，其中正确的（规范化的）架构设计非常重要。
答案 4 :(得分：2)
为了规范化，分解表会有成本。该成本有一个性能组件。通过以下方式分解表和连接查询中的数据的性能成本可以保持较低：使用良好的DBMS;正确设计表格;正确设计指标;让优化器完成它的工作;并调整物理设计的DBMS特定功能。
构成实现连接的大型表还需要付出代价。关于更新异常和编程困难的成本在关于规范化的良好教程中概述。组合表还有性能成本。在许多DBMS产品中，将非常大的行加载到内存中的成本比加载较小的行要多。当您组成非常宽的表时，最终会强制DBMS读取非常大的行，只会丢弃大部分读入内存的数据。这可能会使你的速度降低甚至超过正常化。
一般情况下，不要随意进行非规范化。必要时，使用经过前面的人测试的设计学科，即使该学科导致一些非规范化。我建议将星型模式作为这样的学科。它有很多事情要做。并且仍然有很多情况下标准化设计比星型模式设计更好。
学习多套设计原则并学习何时使用哪一组是学习成为专家的第二阶段。
答案 5 :(得分：1)
设置正确的索引后，您的联接可以非常快速地执行。使用SQL事件探查器确定需要创建或更改哪些索引以优化常见查询的性能。确保为数据库设置维护计划，以便每周运行一次（或每天运行一次更改的表），以更新统计信息和索引。
归一化通常优于将数据保存在多个位置。在某些情况下，插入/更新不需要快速进行，并且选择需要非常快速地发生，在这种情况下，如果没有规范化，您可能会更好。即便如此，也不建议过早优化，因此首先要采用标准化结构。
答案 6 :(得分：0)
事实上，通过一些云站点提供的最终超优化之一是使用较少数量的更宽，有限能力的表来提高效率。到目前为止，如果你需要大规模扩展，这是一种方式。但对于任何关系型dbms（不是那些）都不是理想的做法。
如果遇到性能问题，在进行任何非规范化之前，有很多事情需要先处理。