主键和索引 - 查询性能答案

【问题标题】：Primary Keys and Indexes - Query Performance主键和索引 - 查询性能
【发布时间】：2014-02-12 03:10:08
【问题描述】：

我有一个包含超过 100 万条记录的表。表上没有定义键。但是，我们确实定义了聚集索引和非聚集索引。

我想知道当我执行SELECT 查询并包含我们在WHERE 子句中创建索引的列时，是否真的会提高性能？

是否必须拥有主键/唯一键才能利用索引的真正优势？

表格详情：

查询：

select * 
from employee(nolock)
where employeeID = '15' and employeeType = 'FT'

【问题讨论】：

请提供表格布局和您尝试运行的查询示例。
260 列无键未定义标识列。未定义 rowguidcol 列。 1 个聚集索引和 1 个非聚集索引 select * from employee(nolock) where employeeID = '15' and employeeType = 'FT'
聚集/非聚集索引中使用的列和数据类型是什么？
使用SELECT * 时，您总是面临查询优化器将只使用表扫描/聚集索引扫描而不是执行大量搜索和键查找的风险。如果您要使用SELECT col1, col2, ..., colN ，那么您有可能创建一个覆盖索引，其中包含满足此查询所需的所有列，从而显着

【解决方案1】：

根据我个人的经验，聚集索引在狭窄、唯一且不变的情况下是最好的。聚集键越小（非唯一聚集索引添加 4 字节“唯一符”）越好，因为它会在后续非聚集索引上创建更密集的叶页。

假设您当前有一个整数上的非唯一聚集索引（假设employeeID 是一个整数），那么每个键的大小都会有效地加倍到唯一性（整数中的4 和唯一性中的4）。

非唯一/唯一聚集索引之间的区别在于非聚集叶行分别适合一个页面的 1000 行和 2000 行。更密集的非聚集叶页意味着更快地遍历索引级别并节省磁盘空间（4 字节的 1000000 行保存的行相当于每个非聚集索引大约 3 gigs）。

其中很多都是基于您的表上的假设。

TLDR：窄聚集索引键是最好的；使其成为强制唯一性并防止浪费的 4byte 唯一性的主键。

【讨论】：