基于SQL中的群集索引和非群集索引优化查询？

Question

我最近一直念叨如何clustered index和non-clustered index作品。我的理解很简单（如果有错，请纠正我）：

的数据结构，其背clustered和non-clustered indexISB-Tree

Clustered Index：根据索引列（或键）对数据进行物理排序。clustered Index每个只能有一个table。如果index在创建表的过程中未指定No ，则SQL服务器将clustered Index在上自动创建一个primary key column。

问题1 ：由于数据是根据索引进行物理排序的，因此这里不需要额外的空间。这样对吗？那么，当我删除创建的索引时会发生什么？

Non-clustered Index：在中non-clustered indexes，leaf- node树的包含列值和指向数据库中实际行的指针（行定位符）。在这里，需要额外的空间将其non-clustered index table物理存储在磁盘上。但是，一个不受数量的限制non-clustered Indexes.

问题2 ：这是否意味着对非聚集索引列的查询不会导致对数据进行排序？

Q3 ：这里有一个额外的查询，以使用叶节点上的指针来定位实际的行数据。与聚簇索引相比，这将有多少性能差异？

锻炼：

考虑一个Employee表：

CREATE TABLE Employee
(
PersonID int PRIMARY KEY,
Name varchar(255),
age int,
salary int
);

现在，我创建了一个雇员表（在雇员上创建了一个默认的聚集索引）。

此表上的两个频繁查询仅在“年龄”和“工资”列上发生。为了简单起见，让我们假设该表不经常更新

例如：

select * from employee where age > XXX;

select * from employee where salary > XXXX and salary < YYYY;

问题4
：什么是构造索引的最佳方法，以便这两个列上的查询都具有相似的性能。如果我在年龄上具有聚集索引，则“年龄”列上的查询会更快，但比“工资”列上的查询要慢。

问题5 ：在相关说明中，我反复看到应该在具有唯一约束的列上创建索引（聚集索引和非聚集索引）。这是为什么？如果不这样做会发生什么？

Answer 1

对于SQL Server

Q1 如果聚集索引不是唯一的，则仅聚集索引需要额外的空间。SQL
Server将在内部向非唯一的聚集索引添加一个4字节的唯一标识符。这是因为它在非聚簇索引中使用聚簇键作为rowid。

Q2 可以按顺序读取非聚集索引。这可以帮助您在指定订单的地方进行查询。这也可能使合并联接具有吸引力。它还将有助于范围查询（x
col）。

Q3 SQL
Server使用非聚集索引时会进行额外的“书签查找”。但是，仅当它需要不在索引中的列时。还要注意，您可以include在索引的叶级添加额外的列。如果可以使用索引而无需其他查找，则称为覆盖索引。

如果需要书签查找，则它不会占用很高的行数，直到更快地扫描整个聚集索引为止。级别取决于行大小，键大小等。但是通常有5％的行是截止值。

Q4 如果您的应用程序中最重要的事情是尽可能快地进行这两个查询，则可以在这两个查询上创建覆盖索引：

create index IX_1 on employee (age) include (name, salary);
create index IX_2 on employee (salary) include (name, age);

请注意，您不必专门包括集群键，因为非集群索引会将其用作行指针。

Q5
这对于集群键比非集群键更为重要，这是由于使用了唯一符。但是，真正的问题是您的查询是否选择索引。想象一下一个bit值的索引。除非数据分布非常不对称，否则此类索引不太可能用于任何事物。

有关uniquifier的更多信息。想象一下，您和一个非唯一的年龄聚集索引，以及一个非工资性聚集索引。假设您有以下几行：

age | salary | uniqifier
20  | 1000   | 1
20  | 2000   | 2

然后薪水索引将像这样定位行

1000 -> 20, 1
2000 -> 20, 2

假设您运行了查询select * from employee where salary = 1000，并且优化程序选择使用薪水索引。然后，它将从索引查找中找到对（20，1），然后在主数据中查找该值。