SQL Azure перестал использовать индекс

Question

Самые странные часы с использованием SQL Azure.Мы опустили базу данных с 50DTU до 20DTU, и наш процессор прошел через крышу.Оказывается, один из наших основных индексов просто больше не используется .

Индекс все еще существует.У него была 27% фрагментация, которая, как я понимаю, не супер-ужасна, и любой способ не должен мешать SQL использовать ее.Итак, вот что я попробовал (по порядку):

• Реорганизованный индекс - ничего.
• Перестроенный индекс - ничего.
• Уронили и воссоздали - ничего.
• Очистить кэш процессов (используя ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE) - ничего.- - - Удалено и воссоздано с другим именем - сработало .

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

Окончательный рабочий запрос был:

CREATE NONCLUSTERED INDEX [IX_SyncDetail_SyncStatusID_EntityTypeID_ApiConnectionID] ON [client_2].[SyncDetail]
(
    [SyncStatusID] ASC,
    [EntityTypeID] ASC,
    [ApiConnectionID] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]
GO

Это в точности совпадает с исходным индексом (который игнорировался), за исключением того, что a) имя отличается;и б) порядок столбцов, который раньше был EntityTypeID, SyncStatusID, ApiConnectionID.

Я хочу еще раз подчеркнуть, что индекс работал нормально до понижения нашей базы данных.

Итак - любые идеи, чтослучилось?

Answer 1

У вас есть параметризованный запрос.Вы получаете разные планы, основанные на значениях, которые прослушиваются во время компиляции.Различные действия, которые вы делаете, вызывают (ре) компиляции, и вы иногда получаете один и тот же план, а другой - другой.Когда вы получаете выборочное значение, оно выбирает план поиска.Когда вы выбираете неселективное значение, оно выбирает план сканирования.Таким образом, понижение SLO приведет к аварийному переключению и, таким образом, очистит кэш плана -> новая компиляция, новая возможность перехватить значение во время компиляции.При освобождении кеша процедуры -> новая компиляция.Когда вы удаляете или добавляете индекс, он вызывает перекомпиляцию для планов, которые касаются этой таблицы при следующем использовании.

Подробнее об этом поведении можно прочитать здесь: В блоге, объясняющем анализ параметров

Вы также можете использовать хранилище запросов, чтобы просмотреть историю планов запросов (она включенапо умолчанию в SQL Azure). Здесь - ссылка, объясняющая, как вы можете использовать хранилище запросов.Обратите внимание, что с хранилищем запросов вы можете легко вызвать конкретный план запроса, если вы хотите, чтобы только один план выполнялся через пользовательский интерфейс SSMS.

Пространство отслеживания параметров - это то, где у нас есть желание проделать дополнительную работу вбудущее, чтобы сделать это поведение более прозрачным / менее удивительным для клиентов, но пока не смогли этого сделать.Так что, извините, это вас расстраивает, и я надеюсь, что выложенный мной обходной путь разблокирует вас.Будьте уверены, мы хорошо осведомлены о проблемном пространстве и надеемся сделать больше здесь, чтобы в будущем улучшить SQL для таких рабочих нагрузок.