Объясните механизм, из-за которого один и тот же SQL-запрос получает параллельный план только при достаточно высокой оценённой стоимости.
Оптимизатор сравнивает стоимость последовательного и параллельного вариантов. Параллельный план выбирается, когда ожидаемое сокращение времени обработки компенсирует накладные расходы на распределение работы между потоками, их синхронизацию и сбор результатов.
Последовательное выполнение ограничивает обработку одним рабочим потоком, что становится узким местом для больших сканирований, соединений и агрегаций. Параллельные планы появились как способ использовать несколько процессорных ядер и увеличить пропускную способность длительных операций.
Параллелизм не бесплатен: системе нужно разделить входные данные, передать их рабочим потокам и объединить частичные результаты. Поэтому запуск нескольких потоков для маленького запроса может оказаться медленнее последовательного выполнения.
Оптимизатор принимает решение на основе оценённой стоимости, а не фактического времени выполнения. Если статистика ошибочна, он может выбрать параллельный план для небольшого результата или последовательный план для действительно тяжёлой операции.
Избыточный параллелизм увеличивает конкуренцию за процессор, память и пропускную способность диска. При высокой нагрузке это способно ухудшить производительность не только данного запроса, но и других запросов.
Обычно оптимизатор оценивает объём читаемых данных, число строк после фильтрации, стоимость соединений, сортировок и агрегаций. Если суммарная оценка превышает внутренний порог параллелизма, рассматриваются варианты с несколькими потоками; конкретные параметры зависят от СУБД и её настроек.
Параллельный план содержит операции распределения и обмена данными между потоками. Например, строки могут делиться между потоками по диапазонам или хешу ключа, после чего частичные результаты объединяются. Для агрегации часто выполняется локальное накопление по потокам с последующим финальным объединением.
Ключевой фактор — баланс работы. Если один поток получает значительно больше строк, чем остальные, возникает перекос нагрузки: завершения приходится ждать именно его. Для соединений и агрегаций это особенно вероятно при неравномерном распределении значений ключа.
Ошибки оценки кардинальности напрямую влияют на выбор. Заниженная оценка может скрыть выгодность параллельного выполнения, а завышенная — привести к ненужным обменам и расходу ресурсов. Поэтому анализируют не только наличие параллельных операторов, но и различия между оценённым и фактическим числом строк.
Параллельный план также может быть невыгоден для запроса, который должен вернуть первые строки с минимальной задержкой. Последовательный план иногда быстрее начинает выдавать результат, тогда как параллельному требуется время на запуск рабочих потоков и координацию.
Отчёт сканировал крупную таблицу, выполнял группировку и периодически получал последовательный план. После роста объёма данных запрос стал занимать минуты, хотя план формально оставался корректным. Проверка показала, что статистика недооценивала число строк, поэтому расчёт стоимости не достигал порога выбора параллельного варианта.
Рассматривались три решения. Принудительный параллелизм мог быстро помочь, но создавал риск перегрузки процессоров и скрывал проблему оценки. Увеличение степени параллелизма ускоряло отдельный запуск, но повышало конкуренцию за ресурсы. Обновление статистики с последующей проверкой плана устраняло первопричину, но требовало контролируемого тестирования.
Выбрали актуализацию статистики и проверку фактических планов на типичной нагрузке. После исправления оценки оптимизатор стал выбирать параллельный план только для действительно больших объёмов, а короткие запросы сохранили последовательное выполнение. Это дало более стабильное время отчёта без постоянного принуждения плана.
Нет. Параллелизм помогает только тогда, когда работа хорошо делится между потоками, а затраты на обмен данными меньше полученного выигрыша. Узкие места в дисковой подсистеме, блокировки, перекос распределения или последовательная часть плана могут ограничить ускорение.
Оптимизатор рассчитывает стоимость на основе прогнозируемой кардинальности. Если она сильно занижена, тяжёлая операция может получить последовательный план; если завышена, небольшой запрос может получить неоправданный параллелизм. Сравнение оценённых и фактических строк помогает отличить ошибку выбора плана от нехватки аппаратных ресурсов.
Часть работы нельзя распараллелить, а остальные операции требуют синхронизации и обмена данными. Кроме того, неравномерное распределение строк приводит к простою большинства потоков в ожидании самого загруженного. Поэтому увеличение степени параллелизма не гарантирует пропорционального сокращения времени и может ухудшить общую производительность системы.