Почему этот запрос выполняется так медленно?

Помогает ли это, когда вы заставляете временной фильтр срабатывать только после запуска клиентского фильтра?

FI, как в этом примере:

;WITH ClientData AS (   
    SELECT 
         [E2].[CompanyId]
        ,[E2].[Time]
        ,[E1].[Id]
        ,[E1].[Status]
    FROM [dbo].[SplittedSms] AS [E1]
    INNER JOIN [dbo].[Sms] AS [E2]
        ON [E1].[SmsId] = [E2].[Id]
    WHERE  [E2].[CompanyId] = 4563 
      AND ([E1].[NotifiedToClient] IS NULL)
)
SELECT TOP 10
     [CompanyId]    
    ,[Id]
    ,[Status]
FROM ClientData
WHERE [Time] > '2015-04-10'

Создайте индекс для Sms со следующими Index Key Columns (в этом порядке):

1. Идентификатор компании
2. Время

Вам может понадобиться или не понадобиться добавлять Id в качестве Included Column.

Какой тип данных у вашего столбца Time? Если это дата и время, попробуйте преобразовать «2015-04-10» в эквивалентный тип данных, чтобы он мог использовать индекс.

Declare @test datetime
Set @test='2015-04-10'

Затем измените свое условие:

[Extent2].Time > @test    

Сервер sql неявно выполняет приведение к соответствующему типу данных, если существует несоответствие типа данных. И любая функция или операция приведения запрещают использование индексов.

Я нахожусь на том же пути, что и @JonTirjan, индекс только с временем приводит к множеству ключевых запросов, поэтому вы должны попробовать, по крайней мере, следующее:

create index xxx on Sms (Time, CompanyId) include (Id)

or

create index xxx on Sms (CompanyId, Time) include (Id)

Если Id — это ваш кластеризованный индекс, то он не нужен в предложении include. Если значительная часть ваших данных относится к CompanyID 4563, может быть нормально, чтобы он также был включен в столбец.

Проценты, которые вы видите в фактическом плане, являются просто оценками, основанными на предположениях о количестве строк, поэтому они иногда совершенно неверны. Глядя на фактическое количество строк/выполнений + вывод статистики ввода-вывода, вы должны понять, что на самом деле происходит.

На ум приходят две вещи:

1. При добавлении дополнительного ограничения базе данных будет «сложнее» найти первые 10 элементов, соответствующих вашим ограничениям. Найти первые 10 строк, скажем, из 10 000 элементов (из общего числа в 1 миллион) проще, чем найти первые 10 строк, возможно, из 100 элементов (в общей сложности из 1 миллиона).
2. Индекс не используется, вероятно, потому, что индекс создается в столбце даты и времени, что не очень эффективно, если вы также сохраняете в них время. Возможно, вы захотите создать кластеризованный индекс в столбце [time] (но тогда вам придется удалить кластеризованный индекс, который теперь находится в столбце [CompanyId], или вы можете создать вычисляемый столбец, в котором хранится дата-часть [ время], создайте индекс для этого вычисляемого столбца и отфильтруйте этот столбец.

Я обнаружил, что в столбце внешнего ключа (SmsId) в таблице SplittedSms нет индекса. Я сделал один, и кажется, что второй запрос теперь почти так же быстр, как первый.

План выполнения сейчас:

Спасибо всем за усилия.