“聚集索引”和“按子句排序”

Question

Clustered Index和Order by Clause之间有什么区别吗？

我必须从主表中填充下拉列表，以下是查询。

Select Id, Name from Table Order by Name

对于上述任务，我应该使用Order by Clause还是Clustered Index ？

编辑

下面是表的架构

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[lookup]') AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[lookup](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Name] [varchar](50) NULL,
 CONSTRAINT [PK_lookup_ID] PRIMARY KEY NONCLUSTERED
(
    [Id] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
END
GO

IF NOT EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(N'[dbo].[lookup]') AND name = N'IX_lookup_Name')
CREATE CLUSTERED INDEX [IX_lookup_Name] ON [dbo].[lookup]
(
    [Name] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]

我在Name上也有一个聚集索引。 但现在它没有显示在模式中。 对不起，我不知道为什么。

Answer 1

苹果和橙子。 聚集索引是一种存储选项。 ORDER BY 是一个查询选项。 如果您需要有序结果，获取它们的唯一方法是在查询中添加 ORDER BY 子句。 时期。

索引可以帮助查询优化器生成更有效的计划并利用索引作为满足 ORDER BY 要求的手段。 但是，无论是聚集的还是非聚集的，索引的存在都不能保证结果的任何顺序。

因此，您在查询中绝对需要 ORDER BY。 您还可以考虑按Name列索引来帮助查询。 是否使用索引取决于更多因素。 您应该阅读设计索引和引爆点。

Answer 2

索引允许快速搜索过滤“WHERE CLAUSE”，但还具有额外的好处，即数据将被排序。

例子

这就是将数据保存在表中的方式。

ID    Name
1     Jack
2     Bob
3     Jill

如果您在名称（ASC）上添加聚集索引，这就是它的保存方式（主键始终与每个索引一起存储以用于查找信息）

2     Bob
1     Jack
3     Jill

所以使用你的 SQL

Select Id, Name from Table Order by Name

对于没有聚集索引的 select，数据库将检查是否存在有助于更快完成工作的索引。 它不会找到任何东西，因此它将 select 表中的数据，对其进行排序，然后返回。

对于带有聚集索引的 select，数据库将检查是否存在有助于更快完成工作的索引。 它将找到按 ASC 排序的名称索引。 它可以只 select 索引中的 ID 和 Name，然后返回它知道数据已经排序。

因此，如果没有名称索引，数据库必须在每次运行查询时对数据进行排序。 使用索引，在插入或更新数据时进行排序（这会稍微减慢更新速度），不同之处在于它只需要排序一次，而不是每次都需要排序。

Answer 3

如果 Id 是您的主键（这是常见的场景）并且用于连接，您应该在 Id 上创建聚集索引。 但是为了提高搜索性能，您应该在 Name 上创建包含 Id 的非聚集索引。

Answer 4

聚集索引和 order by 子句是两个完全不同的东西。 聚集索引决定存储表中的行如何排序。 order by 子句决定查询结果的排序方式。

非聚集索引在数据库存储中创建另一个“影子表”，该表按索引列排序。 它还包含主键，以便它可以在“真实”表中快速找到正确的行。 数据库设计的最佳实践是在主键上创建聚集索引（除非有反对的理由）。 任何其他需要索引的列都可以在非聚集索引中处理。

为了优化性能， where子句条件可以使用索引比 order by 可以使用索引更重要。

Answer 5

我的第一个问题是：业务用例是什么？ 如果答案是“按名称顺序显示行”，则按名称排序。

既然你提到你已经在 Name 上有一个非聚集索引，你应该对 go 很好。

我还想你无论如何都会过滤“名称”上的数据，所以你已经在使用索引了。

我的第二个想法：您是否过早地优化了这个？ 该表将有数千或数百万行吗？ 如果没有，您可能不会注意到索引是否存在。 如果您确实有数千行，那么下拉框在没有过滤的情况下表现如何？

我们可以做很多猜测，因此最好在您的环境中分析查询。

一般而言，如果数据是相对 static，则将 CLUSTERED INDEX 放在递增值（IDENTITY、创建日期等）上。 并非每个表都需要聚集索引。