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