#azure-sql-database #query-optimization #azure-synapse
Вопрос:
Вопрос: Как вы размещаете подсказки для запросов к таблицам в пулах sql? Кажется, их не узнают?
У нас есть выделенный пул sql synapse с несколькими таблицами, которые мы объединяем в наших запросах и функциях.
Схема была оптимизирована таким образом, что объединение большинства таблиц совпадает с распределением хэшей. По этой причине простые запросы действительно выполняются довольно быстро, так как большинство соединений выполняется на отдельных узлах.
К сожалению, некоторые sql-запросы приводят к сбою в работе оптимизатора запросов, неправильному соединению, что приводит к снижению скорости почти в 10 раз.
Мы пробовали несколько способов указать, какой объединяющий индекс использовать, используя различные «подсказки», например, с (индекс = XXXX) и с (индекс(XXXXX)) и опцией (…), однако выделенные пулы sql, похоже, не распознают никаких подсказок в запросах к таблицам и возвращают ошибки.
Если мы не исправим это, то выделенные пулы sql в значительной степени не подходят для наших бизнес-доменов.
(Также странно, что вокруг этого нет актуальной документации — пулы sql даже близко не реализуют спецификацию t-sql, казалось бы, так странно, что документации, похоже, не существует для фактической реализации?)
Любая помощь в получении подсказок по индексу будет очень признательна!
Редактировать — некоторая справочная информация — хотя имейте в виду — нам нужна информация о том, как заставить ПОДСКАЗКИ работать:
Короче говоря, у нас есть 2 основные таблицы — одна из которых содержит ежедневную исходную информацию, а другая — многодневный поиск свойств.
Базовый запрос соответствует:
select d.*, mp.* from Daily d
inner join MultiDayProperties mp on (mp.id = d.propertyid)
where d.reportDate = '20210914' and....
Обе таблицы являются хэшами, распределенными по mp.id и d.propertyid, с дополнительными табличными индексами на d.Дата отчета и mp.id.
Обычно происходит то, что в ежедневной таблице запрашивается дата отчета, и ежедневные записи объединяются с помощью поиска по таблице многодневных свойств — это оказывается очень быстрым, так как обе записи находятся в одном узле.
Однако при дальнейшем ограничении запроса на многодневные свойства, например «и mp.param1=» abc «и mp.param2= «cde»», мы фактически получаем сканирование таблицы в (огромной) таблице многодневных свойств, с полученными идентификаторами надмножества, которые затем транслируются вместе с ежедневной таблицей. (в 10 раз медленнее)
Такую ситуацию я решил с помощью обычного SQL Server, используя соответствующие подсказки для запросов, однако я не смог сделать это с пулами SQL Synapse.
Короче говоря, мне нужна помощь с подсказками для запросов к таблицам ПУЛОВ SQL :
SQLServer разрешает подсказки для запросов к таблицам — как можно использовать такие подсказки для запросов к таблицам с ПУЛАМИ SQL?
Комментарии:
1. У вас есть пример запроса, который выполняется не так, как ожидалось? Каково распределение для всех задействованных таблиц? Можете ли вы поместить ОБЪЯСНЕНИЕ перед запросом и включить план объяснения для запроса?
2. Привет — обновил вопрос с дополнительной информацией спасибо
3. являются ли таблицы хранилищем столбцов, кластеризованным индексом или кучей? Включена ли функция автоматического создания статистики? docs.microsoft.com/en-us/azure/synapse-analytics/sql/…
4. Статистика включена, и мы автоматически обновляем ее каждое утро. Проблема, по которой я прошу помощи, заключается в том, как использовать ПОДСКАЗКИ для запросов к таблицам (как в обычном sql server) в ПУЛАХ SQL — поскольку они, похоже, не поддерживаются?
Ответ №1:
Итак, хорошо — попробовав несколько вещей, я обнаружил, что в случаях, когда что-то идет не так, добавление следующего в конце запроса исправило проблему:
ОПЦИЯ (ИСПОЛЬЗУЙТЕ ПОДСКАЗКУ ( ‘ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES’ ));
Это остановило шторм ShuffleMoveOperation в тех случаях, когда что-то шло не так.
Подсказки: ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS и ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES также, похоже, помогли (хотя и меньше, чем МИНИМАЛЬНАЯ ИЗБИРАТЕЛЬНОСТЬ)