Какова цель использования OPTION (MAXDOP 1) в SQL Server?

Question

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

Тем не менее, мой вопрос: когда и где лучше всего использовать в запросе?

Answer 1

Как упоминал Kaboing, MAXDOP(n) фактически контролирует количество ядер ЦП, используемых в процессоре запросов.

В полностью бездействующей системе SQL Server попытается извлечь таблицы в память как можно быстрее и объединить их в памяти. Возможно, в вашем случае лучше всего это сделать с одним процессором. Это может иметь тот же эффект, что и использование OPTION (FORCE ORDER), которое заставляет оптимизатор запросов использовать указанный вами порядок соединений. В некоторых случаях я видел, как OPTION (FORCE PLAN) сократил запрос с 26 секунд до 1 секунды времени выполнения.

Books Online продолжает, что возможные значения для MAXDOP:

0 - использует фактическое количество доступных процессоров в зависимости от текущей нагрузки системы. Это значение по умолчанию и рекомендуемая настройка.

1 - Подавляет генерацию параллельного плана. Операция будет выполняться последовательно.

2-64 - ограничивает количество процессоров указанным значением. Меньше процессоров может быть использовано в зависимости от текущей рабочей нагрузки. Если указано значение, превышающее количество доступных процессоров, используется фактическое количество доступных процессоров.

Я не уверен, что лучше всего использовать MAXDOP, однако я бы предположил и сказал, что если у вас есть таблица с 8 разделами, вы бы хотели указать MAXDOP(8) из-за I / О ограничения, но я могу ошибаться.

Вот несколько быстрых ссылок, которые я нашел о MAXDOP:

Электронные книги: степень параллелизма

Общие рекомендации по настройке параметра MAXDOP

Answer 2

Это общая болтовня о параллелизме в SQL Server, она может не ответить на ваш вопрос напрямую.

Из Книг Онлайн, на MAXDOP:

Устанавливает максимальное количество процессоров процессор запросов может использовать для выполнения единый указатель. Меньшее Процессоры могут использоваться в зависимости от текущая нагрузка системы.

См. блог Рики Ли о параллелизме и типе ожидания CXPACKET. Это довольно интересно.

Как правило, в базе данных OLTP мое мнение таково, что если запрос настолько дорог, что его необходимо выполнять на нескольких процессорах, запрос необходимо переписать во что-то более эффективное.

Почему вы получаете лучшие результаты, добавляя MAXDOP (1)? Трудно сказать без фактических планов выполнения, но это может быть настолько просто, что план выполнения полностью отличается от ОПЦИИ, например, с использованием другого индекса (или, более вероятно,) СОЕДИНЕНИЯ по-разному, с использованием соединений MERGE или HASH.

Answer 3

Помимо этого, MAXDOP, по-видимому, можно использовать в качестве обходного пути для потенциально неприятной ошибки:

Возвращенные значения идентичности не всегда корректны

Answer 4

В SQL-сервере есть пара ошибок параллелизации с неправильным вводом. ОПЦИЯ (MAXDOP 1) будет обходить их.

РЕДАКТИРОВАТЬ: Старый. Мое тестирование проводилось в основном на SQL 2005. Большинство из них, похоже, больше не существуют, но время от времени мы подвергаем сомнению предположение, что SQL 2014 делает что-то глупое, и мы возвращаемся к старому пути, и он работает. Нам никогда не удавалось продемонстрировать, что это было не просто плохое создание плана в более поздних случаях, хотя, поскольку на SQL-сервер можно положиться, чтобы получить правильный путь в новых версиях. Поскольку все случаи были связаны с запросами ввода-вывода, MAXDOP 1 не повредит.

Answer 5

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

Если простые запросы становятся ненужными, они могут принести больше проблем, чем решить один. Однако перед добавлением MAXDOP в запрос в виде исправления «колено-рывок» необходимо проверить некоторые настройки сервера.

В Джеремия Пешка - Пять настроек SQL Server, которые нужно изменить , MAXDOP и «СТОИМОСТЬ ДЛЯ ПАРАЛЛЕЛИЗМА» (CTFP) упоминаются как важные настройки для проверки.

Примечание. Пол Уайт упомянул max server memory в качестве параметра для проверки в ответ на Проблема производительности после перехода с SQL Server 2005 на 2012 . Хорошая статья для чтения в КБ: Использование большого объема памяти может привести к неэффективному плану в SQL Server

Джонатан Кейайас - Настройка «порога стоимости параллелизма» из кэша плана помогает найти хорошее значение для CTFP.

Почему игнорируется порог стоимости параллелизма?

Аарон Бертран - Шесть причин, по которым вам стоит нервничать из-за параллелизма обсуждает какой-то сценарий, в котором MAXDOP является решением.

Компоненты, блокирующие параллелизм, упомянуты в Пол Уайт - Принудительный план выполнения параллельных запросов