为什么我使用我制作的索引时查询速度较慢？

我已在下表中，与的EntityFramework 6.1制作：为什么我使用我制作的索引时查询速度较慢？

CREATE TABLE [dbo].[MachineryReading] (
    [Id]     INT    IDENTITY (1, 1) NOT NULL, 
    [Location]   [sys].[geometry] NULL, 
    [Latitude]   FLOAT (53)  NOT NULL, 
    [Longitude]   FLOAT (53)  NOT NULL, 
    [Altitude]   FLOAT (53)  NULL, 
    [Odometer]   INT    NULL, 
    [Speed]    FLOAT (53)  NULL, 
    [BatteryLevel]  INT    NULL, 
    [PinFlags]   BIGINT   NOT NULL, 
    [DateRecorded]  DATETIME   NOT NULL, 
    [DateReceived]  DATETIME   NOT NULL, 
    [Satellites]   INT    NOT NULL, 
    [HDOP]    FLOAT (53)  NOT NULL, 
    [MachineryId]  INT    NOT NULL, 
    [TrackerId]   INT    NOT NULL, 
    [ReportType]   NVARCHAR (1)  NULL, 
    [FixStatus]   INT    DEFAULT ((0)) NOT NULL, 
    [AlarmStatus]  INT    DEFAULT ((0)) NOT NULL, 
    [OperationalSeconds] INT    DEFAULT ((0)) NOT NULL, 
    CONSTRAINT [PK_dbo.MachineryReading] PRIMARY KEY CLUSTERED ([Id] ASC), 
    CONSTRAINT [FK_dbo.MachineryReading_dbo.Machinery_MachineryId] FOREIGN KEY ([MachineryId]) REFERENCES [dbo].[Machinery] ([Id]) ON DELETE CASCADE, 
    CONSTRAINT [FK_dbo.MachineryReading_dbo.Tracker_TrackerId] FOREIGN KEY ([TrackerId]) REFERENCES [dbo].[Tracker] ([Id]) ON DELETE CASCADE 
); 

GO 
CREATE NONCLUSTERED INDEX [IX_MachineryId] 
    ON [dbo].[MachineryReading]([MachineryId] ASC); 


GO 
CREATE NONCLUSTERED INDEX [IX_TrackerId] 
    ON [dbo].[MachineryReading]([TrackerId] ASC);

那是一个大量的信息，而我们最常见（最慢）的查询只使用它的一个子集：

SELECT TOP 1 OperationalSeconds 
    FROM MachineryReading 
    WHERE MachineryId = @id 
    AND DateRecorded > @start 
    AND DateRecorded < @end 
    AND OperationalSeconds <> 0

的表存储了几百万行，从大约2012年开始记录，尽管我们的代码设置为从2000年开始进行一些搜索。它的运行速度非常缓慢，因此我使用的一个人根据DateRecorded对表格进行了分区：

ALTER PARTITION SCHEME PartitionSchemeMonthRange NEXT USED [Primary] 
ALTER PARTITION FUNCTION [PartitionFunctionMonthRange]() SPLIT RANGE(N'2016-01-01T00:00:00.000') 

ALTER PARTITION SCHEME PartitionSchemeMonthRange NEXT USED [Primary] 
ALTER PARTITION FUNCTION [PartitionFunctionMonthRange]() SPLIT RANGE(N'2016-02-01T00:00:00.000') 
... 

CREATE UNIQUE CLUSTERED INDEX [PK_dbo.MachineryReadingPs] ON MachineryReading(DateRecorded, Id) ON PartitionSchemeMonthRange(DateRecorded)

但是，上面的查询仍然运行缓慢。所以，最重要的是，我做了另一个指标：

CREATE NONCLUSTERED INDEX [IX_MachineryId_DateRecorded] 
    ON [dbo].[MachineryReading]([DateRecorded] ASC, [MachineryId] ASC) 
    INCLUDE([OperationalSeconds], [FixStatus]);

再次执行该查询，执行计划表明它完全无视我刚才提出的指标，转而选择固定扫描和索引上IX_MachineryId求。这在很短的日期范围内工作很快，但对于获得总运行时间非常可怕。我可以处理：WITH(INDEX(IX_MachineryId_DateRecorded))。

没有。它实际上运行显着较慢，当使用我专门为该查询制作的索引！是什么赋予了？我能做些什么更好？

来源

2016-12-15 Andrew Williamson

为什么您在索引中将MachineryId前的DateRecorded？我会以相反的方式做到这一点 –

尝试索引'（MachineryID，DateRecorded）'。拥有它的顺序应该使它对优化器更有利。 *（您使用的顺序会将所有内容按时间顺序排列，建议顺序会将所有内容按机器顺序排列。）* – MatBailie

这是我的拼写错误 - 我将它命名为IX_MachineryId_DateRecorded，它应该按照该顺序排列。这可以解释很多... –

您在索引中的MachineryId前有DateRecord。反转这些以获得更高效的索引。

来源

2016-12-15 04:22:12

有时只需要其他人看到你的错误 –

@AndrewWilliamson这实际上是否最终解决了这个问题？它有多大的区别？ –

它已经取得了显着的差异。出于某种原因，我仍然不得不用'WITH（INDEX（...）'来强制它，但是当我这么做的时候速度要快得多。从几分钟到1秒 –

为什么我使用我制作的索引时查询速度较慢？

回答

相关问题