Небольшой, но интересный анонс для тех, кто пользуется Azure SQL DB.
1-го июля вышел в публичное тестирование Index Advisor для Azure SQL Database.
Index Advisor – инструмент, доступный всем пользователям Azure SQL DB (V12) для создания non-clustered индексов. Index Advisor (IA) выдаёт список рекомендуемых индексов для вашей базы данных. Помогает их создать, а также автоматически протестировать! Анализируя нагрузку запросов и характер доступа к данным, IA выбирает те индексы, которые, по его мнению, принесут наибольший прирост производительности индивидуально для вашего сценария.
Так выглядит главная панель Index Advisor
На портале Microsoft Azure, помощник показывает таблицу с рекомендуемыми индексами. Каждая запись характеризует индекс по положительному влиянию на базу данных, показывает колонки и таблицу на которых будет создан индекс, а также время создание рекомендации.
В чём привлекательность Index Advisor?
Index Advisor работает совершенно прозрачно для пользователя. Сначала он подбирает вам список из нескольких индексов, создание которых максимально повысит производительность базы данных.
Затем, вы «заказываете» создание индекса, и в течение 48 часов вы получите отчет о проделанной работе.
Почему нужно 48 часов, чтобы создать индекс?
Все дело в том, что после создания индекса, Index Advisor проверит насколько хорошо этот он вписался в вашу рабочую нагрузку и, если результат негативный (производительность упала), Index Advisor автоматически удалит созданный им индекс.
48 часов, это максимально время, обычно операция заканчивается быстрее. Всё это без всякого вмешательства со стороны, и без потери соединения (ну и конечно данных).
Что это значит для меня?
Ваш база данных станет работать быстрее, за те же деньги, а на худой конец, ничего не изменится. Разве не стоит попробовать?
Как мне попробовать?
Для того что бы попробовать Index Advisor вам необходимо:
- Azure SQL Database на сервере V12
- База данных которая использовалась в течении некоторого времени.
Важно отметить, что пока Index Advisor даёт рекомендации и позволяет создавать только non-clustered индексы.
Поехали:
- Заходим на портал
- Выбираем базу данных и в разделе Operations записываемся на публичное тестирование Index Advisor.
- Если у вас уже есть рекомендации, поздравляю! Вам повезло, сразу приступайте к оптимизации вашей базы данных.
- В противном случае, придётся подождать пару дней, пока Index Advisor накопит достаточно информации.
- Выбираем индекс из первой таблицы и нажимаем “Create Index” на панели справа.
(Для любопытных: Если нажать “View Script”, то можно увидеть код матрицы посмотреть какой SQL запрос будет выполнен для создания индекса)
Когда создание и тестирование закончится, индекс появится в таблице оконченных операций.
Справа, результативность индекса: 2 запроса выполняютсяна 42% быстрее. Индекс занимает 22MB
Вот и всё!
Эй, а что это за …? Или ой, как круто!
Все чаще Микрософт старается слушать своих пользователей предоставляя разные механизмы обратной связи.
Если вам понравился Index Advisor и его рекомендации, не стесняйтесь об этом сказать. Ну а если он напортачил, или предложил создать глупый индекс, не стесняйтесь вдвойне и сообщите, нажав кнопку “Feedback”.
Документация на MSDN
Disclaimer: Я участвую в работе команды Index Advisor и постараюсь ответь на ваши вопросы, если они появятся.
Комментарии (12)
leschenko
09.07.2015 11:28База данных которая использовалась в течении некоторого времени.
Использовалась после включения IA или вообще?
Если второй вариант, то ничего не рекомендует. Если первый, то сколько ждать?
sitox Автор
09.07.2015 12:19Телеметрия собирается после создания базы данных, включение Index Advisor на это не влияет. (так же как она не влияет на производительность)
Так может случиться, что ваша схема не требует улучшения в данный момент, тогда IA ничего не будет рекомендовать. (Поздравляю!)
Когда IA обнаружит постоянную нагрузку, которую можно уменьшить с помощью индекса, вы увидите новую рекомендацию.
Процесс ожидания зависит от вашей нагрузки, и IA должен быть уверен, прежде чем рекомендовать. Могу сказать, что пару часов будет точно недостаточно.
Вероятно, в будущем, модель оповещения о рекомендации измениться от pull (когда вы проверяете каждую базу данных) на push, когда вам приходит скажем письмо о новой рекомендации.
leschenko
09.07.2015 13:40Это база от рабочего приложения и оно уже давно вышло в люди.
В свое время я довольно плотно наблюдал за временем выполнения отдельных запросов и создавал правильные индексы. Возможно поэтому и нет рекомендаций.
Эх, не удалять же индексы ради теста…sitox Автор
09.07.2015 14:06Да, удалять индексы не стоит.
Надеюсь в следующий раз, Index Advisor поможет вам сэкономить время и силы на наблюдении за запросами.
RedQuark
09.07.2015 16:24Index Advisor видит хинты в запросах? Наблюдал как заблуждается стандартный Index Advisor на БД Sharepoint (там в процедурах куча хинтов понаписано).
sitox Автор
09.07.2015 16:56Нет, Index Advisor не смотрит на текст запроса. Он смотрит на характер доступа к данным и нагрузку. Если нагрузка постоянная и есть место для улучшения, он рекомендует индекс.
Насколько я понимаю, подсказки в запросах, говорят какой план выполнения запроса выбрать. И скорее всего этот план уже достаточно хороший.
(В этом SharePoint очень строг, разработчики предпочитают все контролировать сами)RedQuark
09.07.2015 17:19Просто поделюсь наболевшим: из-за прибитых планов к запросу, анализатор постоянно советует создать бесполезные индексы(у вас, я так понял, случиться откат, раз есть наблюдение после). Разработчики SharePoint творят странные вещи, создают табличную функцию с параметрами и по этим параметрам прибивают план в запросе функции. Это гениальное решение идеально пока не встречается запрос использующий это идеальное творение в своих целях: select * from dbo.zzz(flag1,flag2) where Field2='1'. План не перестраивается оптимально и БД ложится. Запрос системный.
RedQuark
09.07.2015 17:061) Можно чуть подробней про анализ характер доступа к данным? Сотни индексов не будет создавать на таблицах где идут постоянные IUD?
2) Есть прогнозный показатель размера индекса скажем через год? (После старта проекта он 10 MB, а через год уже 10GB)
3) В алгоритме оценки участвует параметр степени влияния времени выполнения запроса на другие запросы? Если бы Index Advisor умел ускорять индексами запросы которые долго блокируют ресурсы это было бы явным шагом вперед по сравнению со стандартным анализом CPU, read, duration.
4) Рекомендовать удалить индекс умеет? Скорей всего будут появляться индексы покрывающие предыдущие.
Было бы интересно видеть сколько секунд времени будет экономиться в день от ввода индекса. (пожелания, мысли в слух)
diamond3
Для обычного, не-облачного SQL Server такое появится?
vladimirkolyada
Уже давно есть Tuning Advisor идущая в комплекте. Работает по тому же принципу, от туда наверняка и взято ядро. Профайлинг — анализ — результаты. Причем стандартный умеет не только индексы. И уверен, что есть миллион других приложений, из разряда редгейтов и так далее.
minamoto
Скорее используется общее ядро — системные DMV sys.dm_db_missing_index_groups, sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_details.
Возможно, используется расширенная оценка для определения, насколько индекс ухудшит производительность вставки и сколько места займет.
sitox Автор
Индекс действительно создаётся, и наблюдается в течении некоторого времени, если производительность падает, то он удаляется.