Настройки сеанса join_*

Эти настройки доступны в system.settings и автоматически сгенерированы на основе исходного кода. Указывает, какой алгоритм JOIN используется. Можно указать несколько алгоритмов; для конкретного запроса будет выбран доступный вариант в зависимости от kind/strictness и движка таблицы. Большинство алгоритмов влияют на запрос только тогда, когда именно они выбраны для его выполнения. Однако некоторые изменяют планирование уже при самом наличии в списке — даже как резервный вариант с более низким приоритетом, который в итоге не выбирается, — поскольку решение принимается до выбора алгоритма. Есть два таких эффекта:

• Вывод типов ключей JOIN становится строже (например, соединение слиянием не может соединять ключи разных типов, такие как String и Nullable(String)). Это может изменить типы результатов столбцов USING и привести к сбою JOIN с таблицей движка Join с ошибкой TYPE_MISMATCH. Срабатывает для full_sorting_merge и parallel_full_sorting_merge.
• ORDER BY ... LIMIT на сохраняемой стороне JOIN получает явную сортировку вместо чтения в порядке primary key, поскольку предполагается, что JOIN нарушает упорядоченное чтение (соединение слиянием вставляет собственную сортировку перед JOIN; частичное соединение слиянием повторно сортирует левые блоки; JOIN, который может создавать отложенные блоки, также не передаёт упорядоченное чтение). Результат тот же, но план менее эффективен. Срабатывает для full_sorting_merge, parallel_full_sorting_merge, partial_merge, prefer_partial_merge, grace_hash и auto, а также при ненулевом значении max_bytes_before_external_join / max_bytes_ratio_before_external_join.

Оба эффекта применяются, даже если запрос в итоге выполняется с hash или другим алгоритмом. Если это нежелательно, не указывайте перечисленные выше алгоритмы в join_algorithm для затронутых запросов. Возможные значения:

• grace_hash

Используется Grace hash join. Grace hash — это вариант алгоритма, обеспечивающий производительное выполнение сложных JOIN при ограниченном потреблении памяти. На первом этапе grace JOIN считывает правую таблицу и разбивает её на N бакетов в зависимости от значения hash в столбцах ключа (изначально N равно grace_hash_join_initial_buckets). Это делается так, чтобы каждый бакет можно было обрабатывать независимо. Строки из первого бакета добавляются во внутреннюю hash table, а остальные сохраняются на disk. Если hash table вырастает сверх memory limit (например, заданного через max_bytes_in_join), количество бакетов увеличивается, и для каждой строки заново определяется назначенный бакет. Все строки, которые не принадлежат текущему бакету, сбрасываются и перераспределяются. Поддерживает INNER/LEFT/RIGHT/FULL ALL/ANY JOIN.

• hash

Используется алгоритм Hash join. Это наиболее универсальная реализация, поддерживающая все комбинации kind и strictness, а также несколько ключей JOIN, объединённых с помощью OR в секции JOIN ON. При использовании алгоритма hash правая часть JOIN загружается в оперативную память.

• parallel_hash

Вариант hash JOIN, который разбивает данные на бакеты и параллельно строит несколько hash table вместо одной, чтобы ускорить этот процесс. При использовании алгоритма parallel_hash правая часть JOIN загружается в оперативную память.

• partial_merge

Вариант алгоритма sort-merge, в котором полностью сортируется только правая таблица. RIGHT JOIN и FULL JOIN поддерживаются только со strictness ALL (SEMI, ANTI, ANY и ASOF не поддерживаются). При использовании алгоритма partial_merge ClickHouse сортирует данные и выгружает их на disk. Алгоритм partial_merge в ClickHouse немного отличается от классической реализации. Сначала ClickHouse сортирует правую таблицу по join keys блоками и создаёт min-max index для отсортированных блоков. Затем он сортирует части левой таблицы по join key и выполняет их JOIN с правой таблицей. Min-max index также используется для пропуска ненужных блоков правой таблицы.

• direct

Алгоритм direct (также известный как nested loop) выполняет lookup в правой таблице, используя строки из левой таблицы в качестве ключей. Он поддерживается специальными хранилищами, такими как Dictionary, EmbeddedRocksDB и таблицами MergeTree. Для таблиц MergeTree алгоритм передаёт фильтры по join key напрямую на уровень хранения. Это может быть эффективнее, если ключ позволяет использовать primary key index таблицы для lookup; в противном случае для каждого блока левой таблицы выполняется полное сканирование правой таблицы. Поддерживает INNER и LEFT joins и только одностолбцовые ключи JOIN по равенству без дополнительных условий.

• auto

Если установлено значение auto, сначала пробуется hash JOIN, а затем алгоритм на лету переключается на другой, если превышается memory limit.

• full_sorting_merge

Алгоритм sort-merge с полной сортировкой соединяемых таблиц перед выполнением JOIN.

• ie_join

Алгоритм IEJoin, основанный на сортировке, для JOIN, в секции ON которого есть два сравнения на неравенство (<, <=, >, >=) между выражениями соединяемых таблиц. Поддерживает ALL INNER/LEFT/RIGHT/FULL JOIN и SEMI/ANTI LEFT/RIGHT JOIN. Позиция в списке задаёт приоритет: если IEJoin указан после других алгоритмов, он используется только когда они неприменимы (в секции ON нет условий равенства); если указан первым, он используется всегда, когда секция ON содержит два условия неравенства. Остальные условия (включая равенства) применяются как фильтр к результату JOIN для ALL INNER JOIN, а для остальных видов вычисляются внутри оператора как остаточное условие, влияющее на сопоставление. Без ie_join в списке INNER JOIN, содержащий только условия неравенства, выполняется как CROSS JOIN с фильтром, а остальные виды не поддерживаются. Оба входа накапливаются в памяти перед выполнением JOIN: max_rows_in_join и max_bytes_in_join ограничивают суммарный объём входных данных обеих сторон (не только правой), а действие при переполнении задаётся через join_overflow_mode; индексы сортировки, которые оператор строит поверх накопленных входных данных, не учитываются в ограничении. Сам оператор JOIN выполняется в одном потоке; распараллеливается только предварительная сортировка входных данных.

• parallel_full_sorting_merge

То же, что full_sorting_merge, но JOIN по равенству, совместимые с hash, сегментируются по hash ключей JOIN на независимые merge JOIN для каждого сегмента, которые выполняются параллельно (до max_threads), вместо одного merge JOIN. Это сохраняет низкое потоковое использование памяти merge JOIN при задействовании всех потоков, а результат не упорядочен. Hash-сегментирование по ключам JOIN применяется только к простым JOIN по равенству для типов ключей, hash которых согласуется со сравнением merge JOIN, и только если ни одна из сторон уже не отсортирована. Оно пропускается в следующих случаях:

• JOIN ASOF и типы ключей floating-point / JSON / Object / Dynamic: их hash несовместимы со сравнением merge JOIN, поэтому равные ключи могут попасть в разные сегменты.
• Стороны, которые уже отсортированы (чтение MergeTree по порядку или любые предварительно отсортированные входные данные): сохраняющее порядок распределение по merge JOIN для каждого сегмента может привести к взаимной блокировке конвейера. Вместо этого сохраняются чтение по порядку и его оптимизация read_in_order_use_virtual_row.
• Когда инициатор строит распределённый план (make_distributed_plan), поскольку распределённая сортировка не сериализуема для удалённого выполнения. Локальный односегментный план и фрагменты для каждого worker повторно оптимизируются с отключённой этой настройкой, поэтому всё ещё могут быть сегментированы.

Пропуск отключает только это преобразование, а не параллелизм в целом: JOIN выполняется как один full_sorting_merge, а стороны MergeTree с чтением по порядку всё ещё могут быть сегментированы в источнике по диапазонам primary key (которые упорядочиваются тем же сравнением, что использует JOIN, поэтому равные ключи остаются вместе), если включён query_plan_join_shard_by_pk_ranges.

• prefer_partial_merge

ClickHouse всегда пытается использовать JOIN partial_merge, если это возможно; в противном случае используется hash. Устарело, то же самое, что partial_merge,hash.

• default (deprecated)

Устаревшее значение, больше его не используйте. То же самое, что direct,hash, то есть сначала используется direct join, а затем hash join (в этом порядке). Изменяет поведение операций JOIN со strictness ANY, когда в правой таблице для ключа есть более одной совпадающей строки. Возможные значения:

• 0 — Если в правой таблице есть более одной совпадающей строки, присоединяется только первая найденная.
• 1 — Если в правой таблице есть более одной совпадающей строки, присоединяется только последняя найденная.

См. также:

• предложение JOIN
• движок таблицы Join
• join_default_strictness

Задаёт strictness по умолчанию для секций JOIN. Возможные значения:

• ALL — Если в правой таблице есть несколько совпадающих строк, ClickHouse создаёт декартово произведение из совпадающих строк. Это обычное поведение JOIN в стандартном SQL.
• ANY — Если в правой таблице есть несколько совпадающих строк, присоединяется только первая найденная. Если в правой таблице есть только одна совпадающая строка, результаты ANY и ALL будут одинаковыми.
• ASOF — Для соединения последовательностей с неточным совпадением.
• Empty string — Если в запросе не указаны ALL или ANY, ClickHouse генерирует исключение.

Ограничивает количество файлов, используемых для параллельной сортировки в операциях MergeJoin при их выполнении на диске. Чем больше значение настройки, тем больше используется оперативной памяти и тем меньше требуется дисковых операций ввода-вывода. Возможные значения:

• Любое положительное целое число, начиная с 2.

Нижний порог среднего числа строк на ключ в правой таблице, определяющий, следует ли использовать вывод по списку строк при hash JOIN. Определяет, какое действие выполняет ClickHouse, когда при JOIN достигается одно из следующих ограничений:

• max_bytes_in_join
• max_rows_in_join

Этот параметр действует только для значений hash, parallel_hash и ie_join параметра join_algorithm. Другие алгоритмы (например, partial_merge, grace_hash, auto) обрабатывают эти ограничения иначе — выгружают данные на диск, переразбивают их на партиции или переключают стратегию — см. join_algorithm. Возможные значения:

• THROW — ClickHouse генерирует исключение и останавливает запрос.
• BREAK — ClickHouse останавливает запрос и не генерирует исключение.

Значение по умолчанию: THROW. См. также

• предложение JOIN
• движок таблицы Join

Задает поведение JOIN. При слиянии таблиц могут появляться пустые ячейки. ClickHouse заполняет их по-разному в зависимости от этой настройки. Возможные значения:

• 0 — Пустые ячейки заполняются значением по умолчанию для типа соответствующего поля.
• 1 — JOIN ведет себя так же, как в стандартном SQL. Тип соответствующего поля преобразуется в Nullable, а пустые ячейки заполняются значением NULL.