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

Question

我最近一直在阅读clustered index 和non-clustered index 的工作原理。我的理解简单来说（如果有错请纠正我）：

支持clustered和non-clustered index的数据结构是B-Tree

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

Q1：由于数据是根据索引进行物理排序的，所以这里不需要额外的空间。它是否正确？那么当我删除我创建的索引时会发生什么？

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

Q2：是不是表示对非聚集索引列的查询不会得到排序后的数据？

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;

Q4 ：构建索引的最佳方法是什么，以便对这两个列的查询具有相似的性能。如果我对年龄有聚集索引，年龄列上的查询会更快，但比薪水列上的速度会慢。

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

非常感谢 我读的帖子在这里：

http://javarevisited.blogspot.com/2013/08/difference-between-clustered-index-and-nonclustered-index-sql-server-database.html

http://msdn.microsoft.com/en-us/library/ms190457.aspx

Clustered vs Non-Clustered

What do Clustered and Non clustered index actually mean?

What are the differences between a clustered and a non-clustered index?

How does database indexing work?

Answer 1

我不了解 Microsoft SQL Server 的内部结构，但我可以回答 MySQL，您已标记为您的问题。其他实现的细节可能会有所不同。

Q1。是的，聚集索引不需要额外的空间。

如果删除聚集索引会发生什么？ MySQL 的 InnoDB 引擎总是使用主键（或第一个非空唯一键）作为聚集索引。如果定义没有主键的表，或者删除现有表的主键，InnoDB generates an internal artificial key for the clustered index。此内部键没有可引用它的逻辑列。

Q2.不保证使用非聚集索引的查询返回的行顺序。实际上，它是访问行的顺序。如果您需要按特定顺序返回行，则应在查询中使用 ORDER BY。如果优化器可以推断出您想要的顺序与它访问行的顺序相同（索引顺序，无论是聚集索引还是非聚集索引），那么它可以跳过排序步骤。

Q3. InnoDB 非聚集索引在索引的叶子上没有指向相应行的指针，它具有主键的值。所以在非聚集索引中查找实际上是两次 B 树搜索，第一次查找非聚集索引的叶子，然后在聚集索引中进行第二次搜索。

这是单个 B 树搜索成本的两倍（或多或少），因此 InnoDB 有一个称为 Adaptive Hash Index 的额外功能。经常搜索的值被缓存在 AHI 中，下次查询搜索缓存的值时，它可以进行 O(1) 查找。在 AHI 缓存中，它直接找到指向聚集索引的叶子的指针，因此它在部分时间消除了 both B 树搜索。

这对整体性能的提升程度取决于您搜索之前搜索过的相同值的频率。根据我的经验，哈希搜索与非哈希搜索的比例通常约为 1:2。

Q4. 构建索引以服务于您需要优化的查询。通常，聚集索引是主键或唯一键，至少在 InnoDB 的情况下，这是必需的。 age 和 salary 都不是唯一的。

你可能会喜欢我的演讲，How to Design Indexes, Really。

Q5. 当你声明一个唯一约束时，InnoDB 会自动创建一个索引。如果没有为它存在的索引，您就不能拥有该约束。如果没有索引，插入值时引擎如何确保唯一性？它需要在整个表中搜索该列中的重复值。该索引有助于提高唯一性检查的效率。

Answer 2

对于 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 值的索引。除非数据的分布非常倾斜，否则这样的索引不太可能用于任何事情。

---

有关唯一性的更多信息。想象一下，你和一个关于年龄的非唯一聚集索引和一个关于薪水的非聚集索引。假设您有以下几行：

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

那么薪水索引会像这样定位行

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

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