SQL Server 2008中的新特性——稀疏列、条件过滤索引和列集

作者 Jonathan Allen 译者 张海龙 发布于 2008年9月7日

领域

运维 & 基础架构,

语言 & 开发

主题

.NET ,

SQL Server

标签

SQL Server 2008

Sparse Columns（稀疏列）, Filtered Indexes（条件过滤索引）和Column Sets（列集）是SQL Server 2008中的新特性，它们使我们可以打破1024个列的限制，以及有效地节省磁盘空间，但是，如果使用不当的话，它们就会成为灾难之源。

如其名称所暗示，Spare Column就是为了解决某些列中通常情况下为null值的情形而设计，它节省磁盘空间的能力很是惊人，但是，我们只有在某个列符合如下条件时才能将其定义为该类型。

第一个规则就是一个需要被定义为Sparse Column的列必须是真正稀疏的。当值为null时，数据指针就完全不占用空间，就像这个列不存在一样。但如果是任何其它值，它将会比其它类型的列多占用4个字节的空间。这一规则对bit列（位列）也是有效的，在非null值的情况下，该列值所占用的空间将从0.125字节增长到4.125字节，据此，我们可以算出将bit列定义成Sparse列的临界值是必须要有98%的行值是null。对于其它大一些的字段来说，就会更容易看到空间收益，例如，datetime列的临界值是只要达到52%的行值为null就划算。在这些示例中的临界点我们可以看出，使用Sparse Column时可以节省至少40%的空间。SQL Server在线图书有一个Sparse列定义图表 ，显示了对于各种不同的列类型，在哪种情况下我们才考虑将其定义为Sparse列。

第二个规则是，要时刻记住尽量使用Sparse列进行索引。如果使用普通索引的话，即使你并不打算对它进行查询，它也会因为null值浪费大量的空间。解决方案就是SQL Server的另一个被称作“Filtered Index（条件过滤索引）”的新特性。一个过滤索引有一个where子句用于防止对那些不满足指定条件的行进行索引。对于Sparse列而言，这个条件显然就是where “column_name IS NOT NULL”。

Sparse列的另一个特点就是会比普通的列要慢，所以，对于那些对CPU性能敏感胜过I/O的查询，应该考虑避免使用Sparse列，这是一个判断是否使用Sparse列的边界条件。

如果不能使用Sparse列的话，在普通的列上建立Filtered Index也是一种替代方案，它既能有效地缩小索引占用的空间，又能避开Sparse列的限制。如前所述，在过滤时，可以在判断该列的行值是否为空以外，增加一些其它的过滤条件。

如果你想打破1024个列的限制，那就必须寻求Column Set的帮助。Column Set允许我们在查询时将超出1024以外的列捆绑到一个单独的XML列中。

根据Yao Qingsong的介绍，微软因为客户的需要保留了1024个列这一限制，

为了能创建多于1024个列，我们必须在表中定义一个columnset列。我们明确地提出这一点，是因为客户不能接受超过1024个列，而我们又不愿意让用户因这一问题无法获取数据。一旦表中定义了columnset列，select *语句将会隐藏所有的Sparse列，代之以这个columnset列。但是，用户仍然可以在查询中select到每个独立的sparse列。

Column Set列必须在表的原始设计中进行定义，如果表中已经有了任意一个Sparse列，就不允许再添加Column Set列。但是，一旦定义了Column Set列，新添加的Sparse列会被自动地添加到Column Set列中。

尽管Column Set看上去是XML，但要尽量小心避免修改它，因为那样做的话会导致它无法再被映射到被绑定的列。

查看英文原文：Sparse Columns, Filtered Indexes, and Column Sets

• 更早的 >