在具有罕见更新/插入的表上实现复合索引

Question

我计划一个数据库模式来存储Amazon产品属性和特定于市场的额外值(如标题、艺术家、体重等)。

到目前为止，有一个带有列的GTIN varchar(13) (PK)产品表。在我的特殊情况下，GTIN可能是EAN/UPC/ISBN标识符。产品中还有一个ASIN char(10)列，用于将GTIN与ASIN相关联。

当EAN和UPC同时存在于同一个ASIN时，会以编程方式捕获并正确处理这些行为，因此请考虑所有ASIN都是唯一的。我在ASIN上定义了一个ASIN，并将它与Products表关联为一对多。

第二个表ProductsData定义了ASIN char(10) (FK)和mid tinyint (Marketplace )。所有ASIN与各自的市场ID一起存储：

rowid    ASIN          mid
1        B0002DB5GS    1
2        B0002DB5GS    44
3        B0002DB5GS    39
4        B0002Y4SYS    1
5        B0002Y4SYS    44
6        B0002Y4SYS    39

正如您注意到的，还有一个rowid int IDENTITY(1,1)列，它是虚拟的，但实现了唯一性。

总结事实：

• 非常罕见的更新
• 相对较少的插入(每个添加的产品在事务中创建3条记录)
• 无缺失
• ASIN列的密集选择
• rowid是一个虚拟的，它只是确保唯一性。

这里有三个问题：

1. 在ASIN和mid上建立一个综合索引值得吗？
2. 如果是，群集还是非群集？
3. 我可以去掉rowid上的聚集索引吗?因为我真的不需要它？

Answer 1

从上面所述，如果性能是一个问题，而且我认为索引是解决方案，我将在ASIN和mid上实现一个非聚集覆盖索引。就像这样：

CREATE NONCLUSTERED INDEX IX_ASIN_COVERING_mid ON ProductsData (ASIN) INCLUDE (mid)

这样，当您加入到ProductsData表时，您可以利用索引来提高性能，而且由于mid是“包含”的，所以它将与索引一起存储，查询引擎不需要再深入。

当然，有许多前进的道路，但根据你的帖子，这是我会倾向于什么。希望能帮上忙！

所以来总结一下你的问题

1. 我的观点是使用覆盖指数而不是综合指数。这是因为听起来你的Products和ProductsData之间的链接是ASIN，而mid就在路上。因此，没有必要将它与index...including中的ASIN组合在一起--在这里，它会很好地工作--在我看来，它是为某种目的而设计的。
2. 如1所述，不聚集，因为聚集索引应该是唯一的。此外，聚集索引维护数据的顺序，因此，如果您创建了一个新产品，并且它的ASIN适合于表中间的某个位置，那么这里就会有开销，因为Server将需要重新排序整个表。
3. 我认为您可以摆脱it...if，您没有将该列用于任何事情，它只是一个虚拟值，您不会在任何查询中使用，那么如果是我，我可能会删除它。