1

我继承了一个数据库，其中每个聚集索引都有聚集索引和额外的重复索引。

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

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

谁能想到这样做的性能优势？

4

6 回答 6

1

对于完全相同的索引，没有性能提升。实际上，它会导致插入和更新的性能损失。但是，如果存在具有不同列顺序的多列索引，则它们可能是有正当理由的。

于 2009-07-14T22:43:57.940 回答
0

我认为会发生的情况是，当指定主键约束时，SQL Server 会自动创建聚集索引（如果另一个索引（非聚集/聚集）尚不存在，则会发生这种情况），然后有人可能创建了一个主键列的非聚集索引。

这种情况会：

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

干杯

于 2009-07-14T22:59:07.583 回答
0

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

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

于 2009-07-14T23:00:11.667 回答
0

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

但是，我可以想象一个产品依赖于一个名为IX_PrimaryKey. 例如

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和 summing的查询TOTAL_CHARGES，SQL 可以使用IX_2用作“覆盖索引”，从索引中满足所有查询细节，而无需接触表。通常，这是您在经过大量测试后在性能调整过程中添加的内容。

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

于 2009-07-14T23:04:24.450 回答
0

也许我想得不够努力，但我看不出有什么理由这样做；聚集索引的本质是数据按照索引的顺序组织。似乎额外的索引完全是浪费。

不过，通过 BOL 挖掘并观看这个问题......

于 2009-07-14T22:45:04.443 回答
0

这样做似乎没有合理的理由，并且会影响性​​能。

我唯一能想到的就是创建一个行宽非常窄的索引，以便每页的行数非常高，从而可以非常快速地扫描/查找。但是由于它不包含其他字段（除了聚集键，它是相同的值）我仍然看不到它的原因。

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

于 2009-07-14T22:51:53.243 回答