Вот краткий обзор: я делаю запрос на выборку. Каждый столбец в WHERE
и ORDER BY
пунктах находятся в одном некластерном индекс IX_MachineryId_DateRecorded
, либо как часть ключа, или в качестве INCLUDE
столбцов. Я выбираю все столбцы, так что это приведет к поиску закладок, но я только беру TOP (1)
, так что сервер может сказать, что поиск нужно выполнить только один раз, в конце.
Самое главное, когда я заставляю запрос использовать индекс IX_MachineryId_DateRecorded
, он выполняется менее чем за секунду. Если я позволю серверу решить, какой индекс использовать, он выбирает IX_MachineryId
, и это занимает до минуты. Это действительно наводит на мысль, что я правильно сделал индекс, а сервер просто принимает неверное решение. Почему?
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);
GO
CREATE NONCLUSTERED INDEX [IX_MachineryId_DateRecorded]
ON [dbo].[MachineryReading]([MachineryId] ASC, [DateRecorded] ASC)
INCLUDE([OperationalSeconds], [FixStatus]);
Таблица разбита на месячные диапазоны (хотя я до сих пор не понимаю, что там происходит).
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)
Запрос, который я обычно запускаю:
SELECT TOP (1) [Id], [Location], [Latitude], [Longitude], [Altitude], [Odometer], [ReportType], [FixStatus], [AlarmStatus], [Speed], [BatteryLevel], [PinFlags], [DateRecorded], [DateReceived], [Satellites], [HDOP], [OperationalSeconds], [MachineryId], [TrackerId]
FROM [dbo].[MachineryReading]
--WITH(INDEX(IX_MachineryId_DateRecorded)) --This makes all the difference
WHERE ([MachineryId] = @p__linq__0) AND ([DateRecorded] >= @p__linq__1) AND ([DateRecorded] < @p__linq__2) AND ([OperationalSeconds] > 0)
ORDER BY [DateRecorded] ASC
План запроса: https://www.brentozar.com/pastetheplan/?id=r1c-RpxNx
План запроса с принудительным индексом: https://www.brentozar.com/pastetheplan/?id=SywwTagVe
Включенные планы являются фактическими планами выполнения, но находятся в промежуточной базе данных (около 1/100 размера живого). Я не решаюсь возиться с живой базой данных, потому что я только начал работать в этой компании около месяца назад.
У меня такое ощущение, что это из-за разбиения, и мой запрос обычно охватывает каждый отдельный раздел (например, когда я хочу получить первый или последний OperationalSeconds
записанный файл для одной машины). Однако все запросы, которые я писал вручную, работают в 10–100 раз быстрее, чем сгенерированные EntityFramework , поэтому я просто собираюсь сделать хранимую процедуру.