Sql server 冗余索引？

我注意到我正在处理的一个数据库中有一个奇怪的索引组合

以下是表格设计：

CREATE TABLE tblABC 
(
    id INT NOT NULL IDENTITY(1,1),
    AnotherId INT NOT NULL, --not unique column
    Othercolumn1 INT,
    OtherColumn2 VARCHAR(10),
    OtherColumn3 DATETIME,
    OtherColumn4 DECIMAL(14, 4),
    OtherColumn5 INT,

    CONSTRAINT idxPKNCU 
        PRIMARY KEY NONCLUSTERED (id)
)

CREATE CLUSTERED INDEX idx1  
    ON tblABC(AnotherId ASC)
CREATE NONCLUSTERED INDEX idx2 
    ON tblABC(AnotherId ASC) INCLUDE(OtherColumn4)
CREATE NONCLUSTERED INDEX idx3 
    ON tblABC (AnotherId) INCLUDE (OtherColumn2, OtherColumn4)

请注意，列id是标识，定义为主键

聚集索引是在列-AnotherId上定义的，此列不是唯一的。 在另一个ID上定义了两个附加的非聚集索引，以及附加的include列

我的观点是，另一个ID上的任何一个非聚集索引都是冗余的（idx2和idx3），因为表的主副本（culstred索引）具有相同的数据

当我检查索引使用情况时，我希望在idx2和idx3上看不到任何使用情况，但idx3有最高的索引查找

我给出了索引设计和使用的截图

我的问题是——这些非聚集索引——idx2和idx3是冗余的吗？优化器可以从聚集索引idx1获得相同的数据。如果没有定义NC索引，它可能会得到它

我错过什么了吗

问候,

纳亚克

---

有两个非常相似的非聚集索引有点奇怪，尽管它们可能会被同等地使用。我还发现，在非唯一字段上创建聚集索引确实很奇怪

查看以下链接以获取信息和一个确定索引使用情况的免费工具。我一直在使用它来查看使用了哪些索引等等

对于非聚集索引-您可以合并和删除未使用的索引，就像您只向它们写入一样，这是对资源的极大浪费。

---

对于聚集索引，你<强> 5 < /强>考虑使用Blz索引工具根据你的发现重做它。

在同一列上有两个NCI（PK／CI）似乎有点奇怪，这部分对我来说并没有太多意义。然后：由于

idx2

和

idx4

之间的唯一区别是包含（或不包含）另一列，我会说是的-只包含另一列的索引是冗余的，并且可以由第二个NCI（包括两个额外列）轻松处理，因为idx2和idx3小于idx1（idx1是完整的表，idx2和idx3仅包含字段的子集），如果只需要索引中包含的那些特定字段，查询idx2和idx3可能需要更少的页面负载。最小的覆盖索引在I/O方面最有效。优化器不关心冗余。任何只需要

其他ID

、

其他Column2

和

其他Column4

的查询都将优先于将idx3改为idx1，甚至需要更多列的查询如果其搜索被idx3完全覆盖（即使还需要额外的CI查找），也会选择idx3。另外，这种“冗余”索引通常是有人运行tuning advisor并让它盲目创建所有索引或获得“缺少索引”的标志一个查询中的提示和盲目地创建索引。这些机制不考虑索引的成本，而只考虑它们对特定查询的好处。有人考虑过一种方法，我们去索引使用的DMV，并找到具有高搜索的聚集索引（例如百万），并添加这样的窄索引。（当然，在验证查询中的用法之后），一个非唯一的聚集索引并不像听起来那么奇怪。考虑一个历史数据表，用一个（不保证是唯一的）索引。时间戳。如果几乎所有查询都涉及在此时间戳上的范围，那么它是聚集索引的最佳候选，而不是从未使用过的代理ID（或者时间戳和ID的唯一组合，它比时间戳和uniquifier占用更多的空间）。聚集索引不应该是非常非唯一的，但如果它仍然满足其他条件，则某些重复项是可以的。（是的，我指的是一个真正的表。）