何时拆分数据库表而不是添加更多列 - 性能 - 数据库设计

Question

问题是添加更多列或拆分数据库表。

假设我有一张表保留：

UserId - Primary Key
Col1
Col2
Col3

现在我将保留另一个数据为Col4 Col5， 但是这些数据对每个UserId都无效。

假设我的主表有200万条记录，这些附加数据仅对25000条记录有效。所以问题是：我应该将另一个表格组成

UserId - Primary Key
Col4
Col5

或

将我的主表用作

UserId - Primary Key
Col1
Col2
Col3
Col4
Col5

我该走哪条路？我关心表现。这些额外的cols是 tinyint ，默认为0而不是null。

SQL server 2008 R2

Answer 1

您没有说现有字段是什么。而且，没有一种名为'tinyBit'的数据类型。

即便如此，仍有两种可能的影响案例：

1）您的表已经包含一个位列，并且您正在添加两个位列

在这种情况下，因为位存储在压缩字节中，所以性能差异无论如何都可以忽略不计。

2）您的表格不包含位列，或者您正在添加tinyint列

在这种情况下，性能会受到影响 - 因为每行会有额外的信息。但是，2,000,000条记录根本不是很大。否定在同一行中存储额外列的成本的一种简单方法是添加使用INCLUDE包含Col1，Col2和Col3列的索引。在这种情况下，查询优化器（QO）通常会使用包含的列而不是聚簇索引查找选择索引上的索引查找，因为它会降低成本。

编辑 - ＆gt;鉴于您的澄清，案例2）适用，并且使用相关列INCLUDED创建索引可能会提高任何现有群集搜索的性能。将有一个插入成本 - 所以它的读/写平衡将取决于它是否值得。

Answer 2

对于只有2M行，可以肯定地说你应该将它保存在一个表中。

MS SQL Server可以有效地存储NULL值（在理想情况下只需单个位），因此您需要许多列和非常特定的NULL分配才能看到任何存储节省。< / p>

通常情况下，垂直分区是为了更好的缓存局部性而完成的，但是最近2M行通常会适合内存，因此我怀疑你是否能够看到任何差异。但是，由于JOIN，你会看到（负）差异。

无论如何，不​​要盲目做任何事情。 衡量有关具有代表性工作负载的实际数据量，并在您知道其影响后才做出决定。