假设我有以下数据库结构：
我的应用程序需要显示包含所有详细信息的文章列表（型号、产品系列、品牌、生产商）。为此，我需要进行更多的 JOIN 以获得所需的数据。
我是否可以通过为 Article 表创建冗余 FK 来提高应用程序的性能，如下所示？它真的提高了性能吗？
【问题讨论】：
标签： database performance foreign-keys denormalization database-indexes
确定设计是否能提高性能的最佳方法是尝试一下；第二种最好的方法是仔细考虑您可能需要运行的查询，然后尝试在您的脑海中对它们进行建模。如果不知道您要运行什么查询，或者您的数据库有多大，就很难知道您是否会看到性能改进。
一般来说，除非您有一个非常大的数据库（假设您在体面的硬件上运行它，并且您已经调整了索引），否则您不会看到对性能的可衡量影响。 “非常大”是指几个表中有数百万行。
如果你真的需要去规范化，我的建议是创建一个显式去规范化的表，而不是用冗余键“污染”你的常规设计。理解一个单独的“应该如何”和“妥协”的设计要容易得多，而不是将两者混合在一起。
为了实现这一点，我会创建一个单独的表 - 也许是“cached_articles”，其中包含列：
article_id
...(article data)
model_id
....(model data)
family_id
...(family data)
brand_id
....(brand data)
producer_id
....(producer data)
您可以通过批处理作业或触发器来维护此表。您应该只让您的应用程序代码写入规范化表，并且只在需要时从缓存表中读取。
您还应该建立一个强大的“一致性检查”机制来识别可能导致应用程序崩溃的数据问题；一旦您的数据库增长到需要这种设计的大小，这些一致性检查就会变得很重要，因为它们会遇到相同的性能问题......
【讨论】：
是的，如果您不想检索层次结构中“中间”对象的任何数据，您可以通过这种方式提高性能。这是一种常见的非规范化形式。请注意，您需要小心不要让不一致的地方溜进来。
我通常会设置一个夜间任务来验证非规范化数据，将错误发送给我并自动修复它们。这并不难做到，并且消除了一类令人讨厌的错误。
人们这样做的另一个原因是将所有表分区在同一个键上。
【讨论】：