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