非聚集索引的候选者答案

【问题标题】：Candidate for Non-Clustered index非聚集索引的候选者
【发布时间】：2013-11-27 00:13:24
【问题描述】：

我有一个如下表结构：

功能列表

ID  - BIGINT - Primary Key  - Clustered Index
VIN - VARCHAR(50)
Text - VARCHAR(50)
Value - VARCHAR(50)

我对此执行的大部分查询都是这样的：

SELECT * FROM FeatureList WHERE VIN = 'ABCD'    --- Will give multiple records

OR 

DELETE FROM FeatureList WHERE VIN = 'ABCD'

我想知道，VIN 列是否适合非聚集索引？或者它可能会降低性能？

【问题讨论】：

为什么 PK 是 BIGINT？你真的要在这张表中拥有超过 20 亿个特征吗？无论如何，在不了解您的系统的其他信息以及额外/更广泛的索引如何影响您的整体工作负载的情况下，将 VIN 集群化可能更有意义。然后至少不需要查找来获取 SELECT * 查询中的其他列...
左大灯，右大灯，左前轮，右前轮……是的，你完全可以在汽车上获得超过 2B 的功能
不在这个阶段....目前我可以看到它增长到.. 5 到 1000 万条记录..但是将其声明为 BIGINT 有什么害处吗？
@billinkc - 你完全明白了我 :)
NCI 的价值值得怀疑（推迟到 AB 或其他人），因为即使引擎寻找到该位置，它仍然需要进行密钥查找才能进入物理索引以获取其余部分选择的数据。如果您没有SELECT *，那么也许 NCI 适合您。

【解决方案1】：

不在 VIN 上声明索引绝对会大大降低性能。每次涉及 VIN 的插入、删除或更新都会对性能造成很小的影响。读取（尤其是当您处理数百万条记录时）运行速度会快几个数量级。

对于 BIGINT 与 INT，我通常选择 BIGINT。是的，它占用了更多的磁盘空间。是的，它占用了更多的内存。不过，对我来说有利的一面是，我永远不必担心将表（以及将 ID 作为外键的所有其他表）迁移到 BIGINT。到过那里。做到了。额外的空间是值得的。

【讨论】：

该表现在确实有数百万条记录..取决于我发布的查询..将 NCI 添加到 VIN 列是否有意义..因为有些人说相反..
@Akon：这在很大程度上取决于您的查询将返回数百万行中的多少行。另外：使用SELECT * 会降低使用索引的可能性；更好地获取仅您真正需要的列 - 而不仅仅是所有内容。所以是的 - VIN 绝对是一个候选人 - 你需要添加索引并衡量它是否真的有助于你的查询。
SELECT * FROM FeatureList WHERE VIN = 'ABCD' 这将提供大约 5 到 10 到 15 条记录.. WHERE 子句在 NCI 中不起作用
我会选择索引。 SELECT * 肯定会影响从查询返回的多少数据，但我不确定我是否同意它会影响索引的使用。缺少 WHERE 子句？绝对地。我很想看到查询计划统计数据来支持这一点。