Fli*_*ter 5 sql indexing clustered-index sql-server-2008
好的,我需要再次拼出这个.我已经在线阅读了这些文章,但我还没有找到明确的答案.
在SQL Server 2008中,我有一个"核心"表,其中包含大约50,000条记录和大量读取活动,在所有查询中以相同的方式使用.此数据每月更新一次,每秒读取数百次.
数据在字段上具有聚簇索引,因为它们经常被访问.假设聚集索引是:
集群指数
Field1 int
Field2 int
Field3 int
Field4 int
Field5 int
现在,没有比这更多的数据,所以将额外的几列放入"包含的列"是有意义的,但SQL Server不允许在聚集索引上包含列.
因此,我们有第二个索引,其字段与Clustered Index基本相同,其他列为"Included Columns".但是,从我读过的内容来看,我认为这可能是多余的？
覆盖索引(非群集)
Field1 int
Field2 int
Field3 int
Field4 int
Field5 int
包括栏目
Field6 varchar(96)
Field7 varchar(96)
非聚集索引ALREADY是否具有其中定义的聚簇索引的列？
如果是这样,那么如何使用NO列创建第二个索引(除了已经在聚簇索引中的内容)？换句话说,我想说"这个索引与聚集索引完全相同......带有几个包含的列".
或者,将所有列放入聚集索引(包括不识别记录的两个列)会更好吗？varchar列确实更频繁地更新(每天几次而不是每月一次),所以我希望将它们保留在聚集索引之外,但我认为它们足够深,它们不会影响索引树足以在发生更改时导致任何重新平衡.
那么,是否有一种有效的方法来设置这些索引,以便该表的所有列都可以通过索引获得而无需返回到表中？
是 - NonClustered Index通过聚簇键访问表中的数据(当表具有聚簇键时,以及当没有聚簇键时访问行ID),因此它将自动包含聚簇索引字段.这也是为什么更改聚簇索引,强制重建所有非聚簇索引的原因.
如果该索引满足大量查询,则包含2个字段的附加NC索引可能有效,但我不确定是否正在解决正确的问题.
在Clustered Key中包含2个以上的字段并不理想,现在在NC索引中确认,您可以看到该表上的每个索引都包含其中的每个索引的群集密钥.
这是您希望群集密钥尽可能地缩小的主要原因,如果有的话,您应该检查群集密钥,并询问为什么要选择5字段群集密钥,并且该选择是否会导致碎片化？
使用聚类键的人工值(Identity)可能会更好,并使用唯一的NC索引来强制使用5字段聚簇键的唯一性.
聚集索引不需要包含。包含意味着在索引树的最低级别存储额外的数据。这是聚集索引中的数据。所以你不需要重叠索引
但是，如果您关心内存占用，那么您需要缩小表。对于 50k 行，我会考虑从 -32768 开始的小整数代理键。然后，您删除每个 NC 索引中 C 键的开销。这意味着您可以拥有问题中提到的覆盖索引。
请注意，一旦您的执行计划被缓存并且数据位于缓存中，那么您的查询将来自内存。您的使用意味着它将在缓存中保留一段时间。缺乏更新意味着您将无法获得统计驱动的重新编译。
但是，如果您的数据几乎是静态的，那么如果性能是一个问题，为什么还要调用 SQL Server呢？缓存它。根据我的缓存评论，删除网络往返可能是您最大的开销。我们将一些查找和缓存外包给客户端以减少服务器负载（在峰值负载下，我们在大约 20 秒内进行了 50k 写入）