我正在查看我们的数据库并注意到在特定表上我们有以下索引：
表：
Col1 INT IDENTITY(1,1) Primary Key
Col2 INT
...
about 15 more columns
....
ColN VARCHAR(50)
....
another 10 more columns
除了 上的标准主键聚集索引Col1，我们还有以下索引：
create nonclustered index [iTable-Col1] ON [dbo].[Table1]
(
Col1
)
include ( ColN )
我们定期搜索Col1并且只想检索ColN. 该索引确实被使用，因为它是包含满足查询所需的所有数据的最小索引。
我的问题是，这个索引对 SQL Server 有什么好处吗？我们是否会更好地放弃它并只在聚集索引上进行搜索？
我唯一的想法是这个索引比聚集索引（25mb vs 300mb）小得多，这可能会使搜索和/或缓存更快。
如果这有什么不同的话，服务器是 SQL Server 2012。
大多数时候，这种类型的索引只对那些列的索引扫描有用。
叶级别之上的索引树结构通常在树级别方面非常相似，因此如果是这种情况，则导航树以进行查找操作（不扫描）的性能差异很小或没有差异。如果你想学习索引内部的基础知识，我有一个视频可以帮助你。
无论如何，回到扫描。该索引有用的原因与其说是索引本身有关，不如说是关于为什么不扫描聚集索引（或将这些数据页保存在内存中）。如果其他列使表相对较宽（根据您提供的大小，我会说它们确实如此，尽管不清楚该表在整个数据库的上下文中有多大），窄索引在某些情况下可能是有益的. 频繁的扫描（或在许多不同的键值上查找）倾向于将整个索引保留在内存中，因此索引越大，用于其他对象的内存空间就越少，当然这会产生更多的 I/O，如果缓冲池很冷。
虽然这是一个罕见的用例（我记得做过一次或两次），但这种索引的最大好处是它将极大地帮助想要使用合并连接来连接该表的查询。（注意：如果索引扫描不合适，请先优化查询！）在查询计划中，对聚集索引的扫描，或在合并连接之前对非聚集索引的扫描和排序可以给出何时可能出现这种情况的指示是个好主意。但同样，这种情况很少见。查询应该足够频繁地执行，或者基表足够昂贵以保持卡在内存中（即，您不需要一直在那里），以证明索引的额外存储和维护是合理的。
如果您不确定现在如何使用此索引，请检查 DMV
sys.dm_db_index_usage_stats。请记住，在服务器重新启动时会重置计数，因此如果您正在考虑删除索引，请确保它在整个业务周期中都没有用。让 SQL Server 回答您的问题，如果索引有用，查询优化器将使用它，否则不会。