【IT168 技术文档】

  多对多表和集簇索引

  多对多表有非常快速的JOIN并允许快速的从一个记录到另一个记录的重新联合。设想有下面这样的数据结构：

  这些结构中的集簇索引是CustomerID和OrderID。组合键是CustomerID/OrderID。下面这个结构的优点：

  JOIN都是基于集簇索引（比非集簇索引JOIN快很多）。

  将一个Order赋给另一个Customer只需要对CustomerOrder表作一个UPDATE操作，这是改动非常少的，只影响到一个集簇索引。因此，它减少了你在更新一个大表时的数据库锁的时间，如Orders表。

  使用多对多表就不需要大表中的一些非集簇索引，如Customer/Orders。因此，它减少大表的维护时间。

  这个方法的一个缺点是CustomerOrder表的碎片（不是连续的）。然而，这并不是一个大问题，因为这个表是相对较小的，它只有2个字段，数据类型也很少，并且只有一个集簇索引。这些本来是在包括CustomerID的Orders表的非集簇索引的减少，带来的好处是大于额外开销的。

  SQL Server 2005的集簇索引和分割表

  SQL Server 2005中的分割表是一些表面上为一个独立的表，但实际上——在存储子系统中——它们包含能够存储在许多文件组（Filegroup）的多个部分。表的部分是根据一个字段的值来分割成不同文件组的。这种方式的分割表会有几个缺点。这里我会说明几个基本的缺点，希望能让你对相关的原因有一些了解。我建议你使用分割表时先学习它的使用方法。

  你可以在这个环境中基于一个字段创建一个集簇索引。但是，如果这个字段不是表用于分割的那个字段，那么集簇索引就被称为非对齐的。如果一个集簇索引是非对齐的，那么任何分区的数据进/出（或合并）都需要你删除集簇索引以及非集簇索引，然后再重建这些索引。这是必要的，因为SQL Server并不知道集簇/非集簇索引的哪部分属于哪个表的分区。毫无疑问，这会带来一定的系统停机时间。

  分割表上的集簇索引应该总包含常规的集簇字段，它是不断增加和静态的，并且它是用于分割数据库表的。如果集簇索引包含用于分割表的字段，那么SQL Server就知道集簇/非集簇索引的哪个部分属于哪个分区。当一个集簇索引包含了用于分割表的字段时，那么这个集簇索引就是“对齐的”。这时表的分区就可以在数据进/出（和合并）而不需要重建集簇/非集簇索引，这样就不会带来额外的系统停机时间。表的INSERT/UPDATE/DELETE操作也会更快，因为这些操作只需要关注处于它们自己分区的索引。

  总结

  SQL Server集簇索引是数据体系结构的一个重要部分，我希望你已经从本文学习中知道了为什么你需要在一开始就仔细设计好集簇索引。集簇索引应该是窄小的、静态的和不断增加的，这对于将来数据库的健壮性是非常重要的。集簇索引可能帮你实现更快速的JOIN和IUD操作，并最小化系统的忙时拥塞时间。

  最后，我们讨论了SQL Server 2005的分割表是如何影响你对集簇索引的使用，集簇索引与分区的“对齐”的意思是什么，以及为什么集簇索引必须按顺序对齐以使分割表正常工作。