2

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

假设我有一张桌子，里面有：

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 服务器 2008 R2

4

2 回答 2

1

你没有说你现有的领域是什么。而且，没有称为“tinyBit”的数据类型。

即便如此，也有两种可能的影响情况：

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

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

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

在这种情况下，性能会受到影响——因为每行会有额外的信息。但是，2,000,000 条记录一点也不大。消除在同一行中存储额外列的成本的一种简单方法是添加一个索引，该索引用于INCLUDE包含 Col1、Col2 和 Col3 列。在这种情况下，查询优化器 (QO) 通常会在包含列的索引上选择索引查找，而不是聚集索引查找，因为它的成本会更低。

编辑-> 鉴于您的说明，案例 2) 适用，并且创建包含相关列的索引可能会比任何现有的集群查找提高性能。会有插入成本 - 因此它是否值得取决于表的读/写平衡。

于 2012-12-12T15:00:19.350 回答
1

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

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

Normally, vertical partitioning is done for better caching locality, but 2M rows will typically fit in memory anyway these days, so I doubt you'll be able to see any difference there either. You will see a (negative) difference because of the JOIN, though.

In any case, don't do anything blindly. Measure on realistic amounts of data with representative workloads and only make a decision after you know what the impact will be.

于 2012-12-13T14:52:45.473 回答