在这种情况下哪种数据库设计更有效？

Posted 2023-05-08

【中文标题】在这种情况下哪种数据库设计更有效？

【英文标题】：Which Database Design is more effective in this scenario?

【发布时间】：2013-09-07 01:49:03

【问题描述】：

数据库设计 1： 有1张桌子

创建表（id int 主键，名称 varchar(20)，描述 varchar(10000)）；

数据库设计 2： 有2张桌子

创建Table1（id int主键，名称varchar(20)）； 创建Table2(id int主键，描述varchar(10000))；

注意：每个 id 都必须有一个与之关联的描述。我们不会像名称那样经常查询描述。

在设计1中，1个简单的查询就可以得到名称和描述，不需要join但是如果我们有100万条记录，那会不会很慢？

在设计 2 中，我们需要连接，因此数据库需要一些搜索和匹配 id --> 这可能会很慢，但我们不会经常查询描述，因此有时会很慢。

那么在这种情况下，更好的设计是什么？

【问题讨论】：

这是无法回答的。找出答案的唯一方法是使用 your 数据集和访问模式来衡量性能。答案在很大程度上取决于许多因素，例如 I/O 带宽、处理器速度、内存、磁盘速度等。您甚至还没有说您将使用哪个数据库，并且对于这个问题没有一个不变的答案。

这并不能改变我对数据和访问模式的回答可能与您不同的事实。您将不得不尝试使用真实世界（您的真实世界）数据来决定。这里没有人能告诉你哪个更好。

【参考方案1】：

这称为vertical partitioning 或“行拆分”，并不是灵丹妙药（什么都不是）。你没有得到“更好的表现”，你只是得到了“不同的表现”。一组性能特征是否优于另一组是一个工程权衡问题，并且因情况而异。

在您的情况下，100 万行可以轻松放入当今硬件上的 DBMS 缓存中，从而产生出色的性能。因此，除非有一些 other reasons 适用，否则请保持简单，在一个表中。

如果它的 10 亿行（或 1 万亿行或任何数字对于当时的内存标准来说太大了），请记住，如果您有 indexed your data correctly，那么在它变得大于缓存。

只有在最极端的情况下，您才需要出于性能原因对表进行垂直分区 - 在这种情况下，您必须在自己的环境中测量您自己的访问模式，并确定它是否带来任何性能优势；是否足够大以弥补增加的 JOINing。

【讨论】：

谢谢你，这就是我需要的所有信息

或者换句话说：使用上面的 CREATE 语句，只要您继续在 PRIMARY KEY 上查询 only，就可以了。

【参考方案2】：

在我看来，这是对 100 万条记录的过度优化。真的没有那么多。您可以尝试通过为虚拟数据库生成大约一百万行的虚拟数据并查询它来测试实际性能。你会看到它的表现。

【讨论】：

一亿条记录怎么样，我们也不像“名称”那样频繁地查询“描述”

在某些时候你必须自己测试它来衡量性能。 1M 和 100M 行之间有很大的区别。此外，“太长”是主观的。你最清楚什么会花费太多时间。您最好的选择是生成虚拟（但具有相似的属性）数据并尝试一堆可能的查询并计算它们的性能。这里没有“一个”答案。