是否可以在具有数百万行的狭窄表上提高查询性能？

我有一个查询，目前平均需要2500毫秒才能完成。我的表很窄，但是有4400万行。我必须选择哪些选项来提高性能，或者说它达到了它的理想水平？

查询

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; 

桌子

CREATE TABLE [dbo].[Heartbeats](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [DeviceID] [int] NOT NULL,
    [IsPUp] [bit] NOT NULL,
    [IsWebUp] [bit] NOT NULL,
    [IsPingUp] [bit] NOT NULL,
    [DateEntered] [datetime] NOT NULL,
 CONSTRAINT [PK_Heartbeats] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

索引

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

添加其他索引会有帮助吗？如果是这样，他们会是什么样子？当前的性能是可以接受的，因为该查询仅偶尔运行，但是我想知道作为学习练习，我可以做些什么来使其更快吗？

更新

当我更改查询以使用强制索引提示时，查询将在50毫秒内执行：

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WITH(INDEX(CommonQueryIndex))
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 

添加正确选择的DeviceID子句也将达到50ms范围：

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' AND DeviceID = 4;

如果我添加ORDER BY [DateEntered], [DeviceID]到原始查询中，则我处于50毫秒范围内：

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 
ORDER BY [DateEntered], [DeviceID];

这些都使用了我期望的索引（CommonQueryIndex），所以，我想我的问题是，有没有办法强制将此索引用于这样的查询？还是表的大小超出了优化程序的范围，我必须只使用ORDER BY或提示？

为什么优化器不适合您的第一个索引：

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

与[DateEntered]列的选择性有关。

您告诉我们您的表有4,400万行。行大小为：

ID为4字节，设备ID为4字节，日期为8字节，4位列为1字节。（标记，Null位图，var col偏移量，col计数）的17字节+ 7字节开销总计每行24字节。

那将很难转换为140k页。要存储这4400万行。

现在，优化程序可以做两件事：

1. 它可以扫描表（集群索引扫描）
2. 或者它可以使用您的索引。然后，对于索引中的每一行，都需要在聚集索引中进行书签查找。

现在，在某个时候，对于在非聚集索引中找到的每个索引条目，在聚集索引中进行所有这些单次查找会变得更加昂贵。该阈值通常是查找总数应超过表页面总数的25％至33％。

因此，在这种情况下：140k / 25％= 35000行140k / 33％= 46666行。

（@ RBarryYoung，35k是总行的0.08％，46666是总行的0.10％，所以我认为这是混乱所在）

因此，如果您的where子句将导致35000到46666行之间的某个位置。（这在top子句的下面！）很有可能不会使用您的非群集，而将使用群集索引扫描。

更改此设置的唯一两种方法是：

1. 使where子句更具选择性。（如果可能的话）
2. 删除*并仅选择几列，以便可以使用覆盖索引。

现在，即使使用select *，也可以创建覆盖索引。但是，这只会为您的插入/更新/删除操作带来巨大的开销。我们将不得不更多地了解您的工作负载（读写），以确保这是最好的解决方案。

从datetime更改为smalldatetime会使聚簇索引的大小减少16％，而非聚簇索引的大小减少24％。

PK集群是否有特定原因？许多人这样做是因为它默认方式，否则他们认为PK必须成簇。不对 聚集索引通常最适合范围查询（例如这一查询）或子表的外键。

聚簇索引的作用是将所有数据聚集在一起，因为数据存储在聚类b树的叶节点上。因此，假设您不要求范围的“过宽”，那么优化器将确切知道b树的哪一部分包含数据，并且无需查找行标识符，然后跳至数据的位置是（就像处理NC索引时一样）。范围的“太宽”是什么？一个荒谬的例子是从一个只有一年记录的表中请求11个月的数据。假设您的统计信息是最新的，那么提取一天的数据应该不是问题。（但是，如果您要查找昨天的数据并且三天没有更新统计信息，那么优化器可能会遇到麻烦。）

由于您正在运行“ SELECT *”查询，因此引擎将需要返回表中的所有列（即使有人添加了此时您的应用程序不需要的新列），因此覆盖索引或索引如果有的话，带有包含的列将无济于事。（如果将表中的每一列都包含在索引中，则说明您做错了。）优化器可能会忽略那些NC索引。

那么该怎么办？

我的建议是删除NC索引，将聚簇PK更改为非聚簇，然后在[DateEntered]上创建聚簇索引。除非另有证明，否则越简单越好。

只要您在那里有“ *”，那么我可以想象的唯一会大不同的就是将索引定义更改为：

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)INCLUDE (ID, IsWebUp, IsPingUp, IsPUp)
 WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

正如我在评论中指出的那样，它应该使用该索引，但是如果没有，您可以使用ORDER BY或索引提示来说服它。

我会对此有所不同。

• 是的，我知道这是一个旧线程，但我对此很感兴趣。

我将转储datetime列-将其更改为int。有一个查询表或为您的日期进行转换。

转储聚集索引-将其保留为堆，并在表示日期的新INT列上创建一个非聚集索引。即今天是20121015。该顺序很重要。根据加载表的频率，以DESC顺序创建该索引。维护成本会更高，您将需要引入填充因子或分区。分区也将有助于减少运行时间。

最后，如果可以使用SQL 2012，请尝试使用SEQUENCE-对于插入，它的性能将超过identity（）。