Question

我继承了一个数据库，其中每个聚集索引都有聚簇索引和附加重复索引。

即 IX_PrimaryKey是列ID的聚簇索引。 IX_ID是列ID上的非聚集索引。

我想清理这些重复的非聚集索引，我想查看是否有人能想到这样做的理由。

有人会想到这样做的性能优势吗？

Answer 1

对于完全相同的索引，没有性能提升。实际上，它会导致插入和更新性能下降。但是，如果存在具有不同列顺序的多列索引，则可能存在有效原因。

Answer 2

也许我的思维不够，但我看不出有任何理由这样做;聚簇索引的本质是数据按索引的顺序组织。似乎额外的指数完全是浪费。

通过BOL挖掘并观察这个问题，但是......

Answer 3

这样做似乎没有明智的理由，并且会有性能受损。

我唯一想到的就是创建一个行宽非常窄的索引，这样每页的行数非常高，使得扫描/搜索非常快。但由于它不包含其他字段（聚集键除外，它是相同的值），我仍然看不出它的原因。

原始创建者很可能不知道PK是默认为聚簇索引并创建了一个NC索引而没有意识到它是重复的。

Answer 4

我认为发生的事情是，当指定主键约束时，SQL Server会自动创建聚簇索引（如果已经存在另一个索引（非聚集/聚簇），则会发生这种情况）为主键列创建了非聚集索引。

这种情况会：

在插入/删除/更新发生时更新索引会对性能产生一些负面影响。
使用额外的磁盘空间。
可能导致死锁。
将有助于更多时间备份/恢复数据库。

欢呼声

Answer 5

创建群集主键将是一种浪费。除非您有使用WHERE ID = 10搜索记录的查询？

您可能希望在列上创建聚簇索引，该索引将在WHERE City ='Sydney'上经常查询。群集意味着SQL将根据聚簇索引对表中的数据进行分组。通过将表中的City值分组，意味着SQL可以更快地搜索数据。

Answer 6

在同一数据上存储两个索引会浪费磁盘空间和维护数据所需的处理。

但是，我可以想象一个产品依赖于名为IX_PrimaryKey的索引的存在。 E.G。

string queryPattern = "select * from {0} as t with (index(IX_PrimaryKey))";

由于叶子是实际数据，因此可以使聚集索引本身占用的空间比其他索引少得多。另一方面，聚簇索引可能更容易被页面拆分，并且一些索引更好地非聚簇。

把它放在一起，我绝对可以想到删除重复索引会是一件坏事的场景：

上面的代码取决于已知的索引名称。
可以将聚簇索引更改为任何非聚集索引的代码。
使用IX_PrimaryKey的存在/不存在以某种方式处理表格的代码。

我不认为这些好的设计，但我绝对可以想象有人这样做。（你把它发布到DailyWTF吗？）

在某些情况下，重叠索引不相同是有意义的：

create index IX_1 on table1 (ID)
create index IX_2 on table1 (ID, TYPE, ORDER_DATE, TOTAL_CHARGES)

如果您严格按ID查找，SQL可以优化并使用IX_1。如果您正在运行基于ID, TYPE, ORDER_DATE的查询并总结TOTAL_CHARGES，则SQL可以使用IX_2作为“覆盖索引”，从而无需触及表即可满足索引中的所有查询详细信息。通常，这是在经过大量测试后在性能调整过程中添加的内容。

在完全相同的字段上查看两个索引的给定示例，我认为不太合适。也许SQL在检查值是否存在时可以使用IX_ID作为“覆盖索引”并绕过IX_PrimaryKey上的某些阻塞？

SQL Server 2000索引 - 群集与非群集

6 个答案: