Я никогда не понимал использование MAXDOP. Я знаю, что он делает запрос быстрее и что это последний элемент, который я могу использовать для оптимизации запросов.Какова цель использования OPTION (MAXDOP 1) в SQL Server?
Однако, мой вопрос в том, когда и где он лучше всего подходит для использования в запросе?
Это общий вопрос о параллелизме в SQL Server, он может не отвечать на ваш вопрос напрямую.
Из книги онлайн, на MAXDOP:
Устанавливает максимальное количество процессоров процессор запросов можно использовать для выполнения одно заявление индекса. Менее процессоры могут использоваться в зависимости от текущей рабочей нагрузки системы.
См. Rickie Lee's blog о параллельности и типе ожидания CXPACKET. Это довольно интересно.
Как правило, в базе данных OLTP я считаю, что если запрос является настолько дорогостоящим, его необходимо выполнить на нескольких процессорах, запрос необходимо переписать в нечто более эффективное.
Почему вы получаете лучшие результаты, добавляя MAXDOP (1)? Трудно сказать без фактических планов выполнения, но это может быть так просто, что план выполнения полностью отличается от того, что без OPTION, например, с использованием другого индекса (или, скорее,) JOINING по-разному, используя соединения MERGE или HASH.
Как упоминалось в Kaboing, MAXDOP(n) фактически контролирует количество ядер процессора, которые используются в процессоре запросов.
В полностью незанятой системе SQL Server попытается как можно быстрее вытащить таблицы в память и объединить их в памяти. Может быть, в вашем случае лучше всего сделать это с помощью одного процессора. Это может иметь такой же эффект, как использование OPTION (FORCE ORDER), что заставляет оптимизатор запросов использовать порядок объединений, который вы указали. В некоторых случаях я видел, что OPTION (FORCE PLAN) уменьшает запрос с 26 секунд до 1 секунды времени выполнения.
Книги Интернет продолжает говорить, что возможные значения для MAXDOP являются:
0 - использует реальное число доступных процессоров в зависимости от текущей рабочей нагрузки системы. Это значение по умолчанию и рекомендуемая настройка.
1 - Подавляет генерацию параллельного плана. Операция будет выполняться последовательно.
2-64 - Ограничивает количество процессоров до указанного значения. В зависимости от текущей рабочей нагрузки может использоваться меньшее количество процессоров. Если указано значение, большее количества доступных ЦП, используется фактическое количество доступных ЦП.
Я не уверен, что лучшее использование MAXDOP, однако я хотел бы сделать предположение и сказать, что если у вас есть таблица с 8 разделами на нем, вы хотели бы указать MAXDOP(8) из-за ввод/вывод ограничения, но я мог ошибаться.
Вот несколько быстрых ссылок, которые я нашел около MAXDOP:
Есть несколько распараллеливания ошибок в SQL-сервере с ненормальным вводом. ВАРИАНТ (MAXDOP 1) будет обходить их.
EDIT: Old. Мое тестирование было сделано в основном на SQL 2005. Большинство из них, похоже, больше не существует, но каждый раз в некоторое время мы ставим под сомнение предположение, что SQL 2014 делает что-то немое, и мы возвращаемся к старому способу, и он работает. Нам никогда не удавалось продемонстрировать, что это было не просто плохое создание плана в более поздних случаях, хотя, поскольку SQL Server можно полагаться, чтобы получить старый путь в новых версиях. Поскольку все случаи были связанными с IO запросами, MAXDOP 1 не повредит.
Не могли бы вы рассказать об этих ошибках? – 2010-06-28 13:02:33
Мне не удалось полностью квалифицировать ошибки, но в частности: когда ожидается, что левое соединение будет соответствовать очень немногим% строк, будет пытаться спутать обе таблицы и объединение циклов, а не поиск по закладкам только с распараллеливанием. – Joshua 2010-06-28 16:50:36
Как что-то в стороне, MAXDOP видимое, может быть использована в качестве обходного пути к потенциально неприятной ошибке:
Добавление моих два цента, на основе вопроса об исполнении я наблюдал.
Если простые запросы становятся ненужными, они могут принести больше проблем, чем решить их. Однако, прежде чем добавлять MAXDOP в запрос как «исправление коленного сустава», есть некоторые настройки сервера для проверки.
В Jeremiah Peschka - Five SQL Server Settings to Change, MAXDOP и «СТОИМОСТЬ ПОТОКА ДЛЯ ПАРАЛЛЕЛЬНИКА» (CTFP) упоминаются как важные настройки для проверки.
Примечание: Пол Уайт упомянул max server memory как установку для проверки в ответ на Performance problem after migration from SQL Server 2005 to 2012. Хорошая статья kb для чтения - Using large amounts of memory can result in an inefficient plan in SQL Server
Jonathan Kehayias - Tuning ‘cost threshold for parallelism’ from the Plan Cache помогает найти полезную информацию для CTFP.
Why is cost threshold for parallelism ignored?
Aaron Bertrand - Six reasons you should be nervous about parallelism имеет обсуждение какой-то сценарий, где MAXDOP является решением.
Параллелизм-Ингибирование компоненты упоминаются в Paul White - Forcing a Parallel Query Execution Plan
Вы должны включать в себя версию и пакет обновления сервера SQL. Возможно, это было исправлено в более поздней версии ... – 2008-12-19 02:54:07