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

【问题标题】：When to split a database table instead of adding more columns - Performance - Database Design何时拆分数据库表而不是添加更多列 - 性能 - 数据库设计
【发布时间】：2012-11-30 05:33:20
【问题描述】：

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

假设我有一张桌子：

UserId - Primary Key
Col1
Col2
Col3

现在我将另一个数据保留为 Col4 Col5，但此数据并非对每个 UserId 都有效。

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

UserId - Primary Key
Col4
Col5

或

使用我的主表作为

UserId - Primary Key
Col1
Col2
Col3
Col4
Col5

我应该走哪条路？我关心性能。这些额外的列是 tinyint 并且默认为 0 而不是 null。

SQL 服务器 2008 R2

【问题讨论】：

真的要看使用场景！非规范化狂热者会告诉你一件事，但对于维护、代码重用、性能或可用性，你可能需要其他东西。您是否有一个映射到 Col1-5 的标准业务对象，需要您返回所有列？你有很多插入、更新、读取
col 4 和 col 5 读取更新非常罕见。虽然 col 1 2 3 读取太多。

标签： sql-server performance database-design split

【解决方案1】：

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

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

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

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

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

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

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

【讨论】：

很抱歉，它是 tinyint 。我不明白您的意思是“您的表格已经包含一个位列，而您正在添加两个位列”？你是什么意思已经包括位列？如果我有其他位列有什么区别？并且这些新列与除主键之外的其余列无关。
如果一行中有 3 位列，则这些位存储在一个字节的 3 位中。您可以添加另外 5 位列，而根本不需要任何更多的每行存储。因此，如果您要添加位列，并且已经存在位列，那么它根本不会影响性能。
谢谢，这很有意义。是的，我已经有 tinyint 列：D 但它们不是位列。所以我想这会有所不同。
@Matt Whitfield，位列是否需要连续才能存储在同一个字节中？
@MonsterMMORPG - 你的问题有什么我没有解决的吗？

【解决方案2】：

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

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

通常，垂直分区是为了更好地缓存局部性，但现在 2M 行通常会适合内存，所以我怀疑你也能看到那里的任何差异。但是，由于 JOIN，您会看到（负）差异。

无论如何，不要盲目地做任何事情。衡量具有代表性工作负载的实际数据量，并且只有在您知道会产生什么影响后才能做出决定。

【讨论】：

感谢您的回答。如果我有 2000 万行怎么办？因为它每天都在增加。
@MonsterMMORPG 即使这对于现代硬件来说可能也不是很多。但是，更重要的是，如果您不断增加数据量，那么我的回答中描述的效果会变得越来越明显，并且越来越需要衡量更好的缓存局部性或 JOIN 是否会在您的特定工作负载中占主导地位。我的预感是 JOIN 将占主导地位，但唯一可以衡量并因此肯定知道的是你。