频繁更改一个或多个外键的引用表的聚簇索引

Question

我特别关注的是在具有许多快速插入和删除的引用表上的聚簇索引的性能。

Table 1 "Collection" collection_pk int (among other fields)
Table 2 "Item" item_pk int (among other fields)
Reference Table "Collection_Items" collection_pk int, item_pk int (combined primary key)

由于主键由两个pks组成，因此会根据组合键创建聚簇索引并在表中按物理排序数据。

我有很多用户在非常频繁地影响“Collection_Items”表及其聚集索引的情况下创建和删除集合以及向这些集合添加和删除项目。

问题部分：由于“Collection_Items”表是如此动态，因为聚集索引不会因为不断求助表行而受到很大影响吗？

如果是，我应该怎样做才能最大限度地减少这种情况？

Answer 1

假设您删除并重新插入给定（复合）主键的一组行：

• 如果表索引是群集的，则删除叶级数据和任何“上层”索引页数据，然后将数据添加回页面，并在上一级页面中添加查找数据。最好将其称为四页书写操作。
• 如果表索引是非群集的，则删除堆数据，“上层”索引数据和叶级索引数据，然后写入堆数据，upper0level索引数据和叶级索引数据。充其量，这是六页写作操作。
• 在任何一种情况下，您都必须担心索引构建/修改，而​​对于非群集，您必须管理对堆表的修改以及跟踪所有索引到数据的引用。

在性能方面，看起来聚集索引似乎是可行的方式......尽管某些操作考虑可能胜过它。 （有多少滴/插入，频率，表格在那时增长[标识值？]或中间[插入新的PK值]，整体大小，更新频率与并发/锁定问题等等。）

避免这种情况的唯一方法是在堆上没有任何索引，并且你不想这样做的可能性很大。

在所有情况下，您可能会遇到高表碎片，因此（取决于整体表大小）定期索引重建可能会很好。

- 根据第一条评论更新------------------

我的初步答案基于以下假设：

• 在给定事务（即INSERT或DELETE语句）中删除的所有行都将用于单个Collection。也就是说，将为单个集合添加/删除N个项目。
• 列（Collection_pk，Item_pk）上存在单个（并且优选聚集的）索引，Collection_pk为firxt列。

通过这种方式，无论何时添加或删除一组行，都只需要修改索引/表的那一小部分（除非涉及数百或更多行）。我的评论是针对那种设计的。

请记住，对于聚簇索引，“表本身”，即数据行， 是聚簇索引的叶级别 - 所以，同样，只有索引的那一部分会永远需要修改。使用堆顶部的非聚集索引，您仍然需要维护这些额外的页面，我认为频繁的删除/插入会导致一些严重的表碎片。

如果（Item_pk，Collection_pk）上存在第二索引，如果您必须按项执行查找，那么这将是必要的，那么它会变得棘手。在这种情况下：

• 出于同样的原因，拥有聚簇索引和非聚集索引会更有效。
• 绝对地，您将保持第二个索引的性能，因为插入/删除操作将始终通过项目优先索引发生。

听起来你没有，也不需要第二个索引，所以不用担心。