> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Настройки сеанса ClickHouse в автоматически сгенерированной группе min_*.

export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
  return <div className="not-prose" style={{
    display: "flex",
    flexWrap: "wrap",
    alignItems: "baseline",
    columnGap: "0.5rem",
    rowGap: "0.125rem",
    margin: "0.375rem 0",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <div style={{
    fontWeight: 600,
    opacity: 0.72
  }}>Тип</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>По умолчанию</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Изменяется без перезапуска
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Эти настройки доступны в [system.settings](/docs/ru/reference/system-tables/settings) и автоматически генерируются на основе [исходного кода](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp).

<div id="min_chunk_bytes_for_parallel_parsing">
  ## min\_chunk\_bytes\_for\_parallel\_parsing
</div>

<SettingsInfoBlock type="NonZeroUInt64" default_value="10485760" />

* Тип: беззнаковое целое число
* Значение по умолчанию: 1 MiB

Минимальный размер фрагмента в байтах, разбираемого каждым потоком параллельно.

<div id="min_compress_block_size">
  ## min\_compress\_block\_size
</div>

<SettingsInfoBlock type="UInt64" default_value="65536" />

Для таблиц [MergeTree](/docs/ru/reference/engines/table-engines/mergetree-family/mergetree). Чтобы уменьшить задержку при обработке запросов, блок сжимается при записи следующей метки, если его размер не меньше `min_compress_block_size`. По умолчанию — 65 536.

Если объем несжатых данных меньше `max_compress_block_size`, фактический размер блока будет не меньше этого значения и не меньше объема данных для одной метки.

Рассмотрим пример. Предположим, что при создании таблицы для `index_granularity` было задано значение 8192.

Записывается столбец типа UInt32 (4 байта на значение). При записи 8192 строк общий объем составит 32 КБ данных. Поскольку min\_compress\_block\_size = 65,536, сжатый блок будет формироваться на каждые две метки.

Записывается столбец URL типа String (средний размер — 60 байт на значение). При записи 8192 строк средний объем будет чуть меньше 500 КБ данных. Поскольку это больше 65,536, сжатый блок будет формироваться для каждой метки. В этом случае при чтении с диска данных в диапазоне одной метки лишние данные распаковываться не будут.

<Note>
  Это настройка экспертного уровня, и не стоит изменять ее, если вы только начинаете работать с ClickHouse.
</Note>

<div id="min_filtered_ratio_for_lazy_final">
  ## min\_filtered\_ratio\_for\_lazy\_final
</div>

<SettingsInfoBlock type="Float" default_value="0.5" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "26.4"},{"label": "0.5"},{"label": "Новая настройка минимальной доли марок, отфильтрованных для продолжения отложенной оптимизации FINAL"}]}]} />

Минимальная доля марок, отфильтрованных при анализе индексов, необходимая для применения отложенной оптимизации FINAL. Если отфильтровано меньше этой доли марок, используется обычный FINAL. Значение 0 отключает эту проверку.

<div id="min_hit_rate_to_use_consecutive_keys_optimization">
  ## min\_hit\_rate\_to\_use\_consecutive\_keys\_optimization
</div>

<SettingsInfoBlock type="Float" default_value="0.5" />

Минимальный коэффициент попаданий кэша, используемого для оптимизации последовательных ключей при агрегации, чтобы она оставалась включенной

<div id="min_os_cpu_wait_time_ratio_to_throw">
  ## min\_os\_cpu\_wait\_time\_ratio\_to\_throw
</div>

<SettingsInfoBlock type="Float" default_value="0" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.5"},{"label": "0"},{"label": "Значения настройки были изменены и бэкпортированы в 25.4"}]}, {"id": "row-2","items": [{"label": "25.4"},{"label": "0"},{"label": "Новая настройка"}]}]} />

Минимальное отношение между временем ожидания CPU ОС (метрика OSCPUWaitMicroseconds) и временем занятости CPU (метрика OSCPUVirtualTimeMicroseconds), при котором может рассматриваться отклонение запросов. Для расчета вероятности используется линейная интерполяция между минимальным и максимальным отношением; в этой точке вероятность равна 0.

<div id="min_outstreams_per_resize_after_split">
  ## min\_outstreams\_per\_resize\_after\_split
</div>

<SettingsInfoBlock type="UInt64" default_value="24" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.6"},{"label": "24"},{"label": "Новая настройка."}]}]} />

Задаёт минимальное количество выходных потоков у процессора `Resize` или `StrictResize` после разделения, выполняемого при генерации конвейера. Если итоговое количество потоков меньше этого значения, операция разделения не выполняется.

<div id="what-is-a-resize-node">
  ### Что такое узел Resize
</div>

Узел `Resize` — это процессор в конвейере выполнения запроса, который регулирует количество потоков данных, проходящих через конвейер. Он может как увеличивать, так и уменьшать число потоков, чтобы сбалансировать рабочую нагрузку между несколькими потоками выполнения или процессорами. Например, если для запроса требуется больший параллелизм, узел `Resize` может разделить один поток на несколько. И наоборот, он может объединить несколько потоков в меньшее число, чтобы объединить обработку данных.

Узел `Resize` обеспечивает равномерное распределение данных между потоками, сохраняя структуру блоков данных. Это помогает эффективнее использовать ресурсы и повышает производительность запросов.

<div id="why-the-resize-node-needs-to-be-split">
  ### Почему узел Resize нужно разделить
</div>

Во время выполнения конвейера за ExecutingGraph::Node::status\_mutex в центральном узле `Resize` возникает сильное contention, особенно в средах с большим числом ядер, и это приводит к следующему:

1. Увеличивается latency для ExecutingGraph::updateNode, что напрямую влияет на query performance.
2. Избыточные циклы CPU впустую расходуются на contention в spin-lock (`native_queued_spin_lock_slowpath`), что снижает эффективность.
3. Снижается utilization CPU, что ограничивает параллелизм и throughput.

<div id="how-the-resize-node-gets-split">
  ### Как разделяется узел Resize
</div>

1. Проверяется число выходных потоков, чтобы убедиться, что разделение можно выполнить: число выходных потоков у каждого процессора после разделения достигает порога `min_outstreams_per_resize_after_split` или превышает его.
2. Узел `Resize` делится на более мелкие узлы `Resize` с одинаковым количеством портов, каждый из которых обрабатывает подмножество входных и выходных потоков.
3. Каждая группа обрабатывается независимо, что снижает конкуренцию за блокировки.

<div id="splitting-resize-node-with-arbitrary-inputsoutputs">
  ### Разделение узла Resize с произвольным числом входов и выходов
</div>

В некоторых случаях, когда число входов/выходов не делится нацело на количество узлов `Resize` после разделения, часть входов подключается к `NullSource`, а часть выходов — к `NullSink`. Это позволяет выполнить разделение, не влияя на общий поток данных.

<div id="purpose-of-the-setting">
  ### Назначение настройки
</div>

Настройка `min_outstreams_per_resize_after_split` гарантирует, что разделение узлов `Resize` оправдано и не приводит к созданию слишком малого числа потоков, что может снизить эффективность параллельной обработки. Задавая минимальное количество выходных потоков, эта настройка помогает поддерживать баланс между параллелизмом и накладными расходами, оптимизируя выполнение запроса в сценариях, связанных с разделением и слиянием потоков.

<div id="disabling-the-setting">
  ### Отключение настройки
</div>

Чтобы отключить split узлов `Resize`, установите для этой настройки значение 0. Это предотвратит split узлов `Resize` при генерации конвейера, и они сохранят исходную структуру без разделения на более мелкие узлы.

<div id="min_table_rows_to_use_projection_index">
  ## min\_table\_rows\_to\_use\_projection\_index
</div>

<SettingsInfoBlock type="UInt64" default_value="1000000" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.11"},{"label": "1000000"},{"label": "новая настройка"}]}]} />

Если оценочное количество строк, которые нужно прочитать из таблицы, больше или равно этому порогу, ClickHouse попытается использовать индекс проекции при выполнении запроса.