【发布时间】：2010-08-30 18:42:06
【问题描述】：
我的问题是关于表上聚集索引的限制。 从理论上讲，在一个表中我们只能有一个聚簇索引。但是，如果我在表格中有日期时间列说“从日期”和“到日期”怎么办？ WHERE 子句中通常需要这些列来填充我的应用程序中的报告。如果我还需要在同一张表中的主键上使用集群索引，那么仍然如何利用其他列上的集群索引？在这种情况下，如果记录较大，我的查询仍然会运行得更慢。
【问题讨论】：
标签： sql sql-server
【发布时间】：2010-08-30 18:42:06
【问题描述】：
实际上，您也可以在一个表上只使用一个聚集索引 - 因为该表的数据是按该聚集索引物理排序的。
如果您在 WHERE 子句中经常需要两个日期时间列，最好的选择是在这两个列上建立一个非聚集索引，并可能包括您经常使用这些查询检索的其他列，以使其成为covering index.
就查询性能而言，好的覆盖非聚集索引和聚集索引之间并没有太大区别。
但是，您不想让聚集索引膨胀，因为这些列也将添加到同一张表上的所有非聚集索引中 - 保持较小，最好是 INT，不断增加，稳定（不会改变) 你应该会没事的。
【讨论】：
-
会考虑的。。谢谢回复！
另一个选项是索引（或物化）视图：您可以在表上创建多个视图，每个视图具有不同的聚集索引。这在报告场景中可能很有用，但索引视图有很多限制，并且会影响修改表数据的查询的性能。 Books Online 包含创建和测试它们所需的所有信息。
我怀疑您的真正需求确实是实施报告解决方案，如果是这样，那么最好正确地做到这一点：使用针对报告优化的架构（Google“星型架构”）创建一个单独的数据库并定期加载数据从主数据库到报告之一。但这是一个需要研究的全新开发领域，我不会急于研究。
【讨论】：
-
views 也是一个不错的选择。谢谢！
如果您需要为同一个表的多个索引提供集群索引表的性能，我看到的唯一途径是为每个集群索引保存一个表的副本。
【讨论】：
聚集索引会影响表中数据的物理存储，因此根据定义只能有一个。您可以扩大聚集索引以包含其他列，但这可能有其自身的缺点。
聚集索引的性能优势在于记录以反映索引的方式存储（这就是为什么对聚集索引的随机插入和更新非常快速地碎片化表的原因），因此基于此索引的查询性能可以与从存储设备读取的性能一样好，但您无法在其他索引上获得这一点。
【讨论】：
我建议您选择可以从集群中获得最大收益的索引，并将其作为您的集群索引。将其余索引设为非聚集索引。您可能需要运行一些测试，以了解将不同的索引设为集群与非集群会带来哪些好处。
分享和享受。
【讨论】：