> ## 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_* セッション設定

> min_* 生成グループに含まれる ClickHouse セッション設定。

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/ja/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

各スレッドが並列にパースする chunk の最小サイズを、バイト単位で指定します。

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

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

[MergeTree](/docs/ja/reference/engines/table-engines/mergetree-family/mergetree) テーブルで使用されます。クエリ処理時のレイテンシを抑えるため、サイズが `min_compress_block_size` 以上の block は、次の mark の書き込み時に圧縮されます。デフォルト値は 65,536 です。

非圧縮データが `max_compress_block_size` 未満の場合、実際の block サイズはこの値以上であり、かつ 1 つの mark 分のデータ量以上になります。

例を見てみましょう。テーブル作成時に `index_granularity` が 8192 に設定されているとします。

UInt32 型のカラム (値 1 つあたり 4 バイト) を書き込む場合、8192 行を書き込むと合計 32 KB のデータになります。min\_compress\_block\_size = 65,536 であるため、圧縮 block は 2 つの mark ごとに作成されます。

String 型の URL カラム (値 1 つあたりの平均サイズが 60 バイト) を書き込む場合、8192 行を書き込むと平均で 500 KB 弱のデータになります。これは 65,536 を超えるため、圧縮 block は mark ごとに作成されます。この場合、ディスクから 1 つの mark の範囲のデータを読み取る際に、余分なデータが展開されることはありません。

<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 最適化を適用するために必要な、フィルタリングされる marks の最小比率に関する新しい設定"}]}]} />

遅延実行 FINAL 最適化において、索引解析によってフィルタリングされる marks の最小比率です。フィルタリングされる marks の割合がこの値を下回る場合は、通常の 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" />

集約における連続キー最適化で使用されるcacheを有効なままにするための最小ヒット率

<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": "新しい設定"}]}]} />

クエリを拒否対象とみなすための、OS の CPU 待機時間 (OSCPUWaitMicroseconds Metric) とビジー時間 (OSCPUVirtualTimeMicroseconds Metric) の最小比率です。確率は最小比率と最大比率の間で線形補間して計算され、この時点での確率は 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>

パイプラインの実行中、中央ハブとなる `Resize` ノードの ExecutingGraph::Node::status\_mutex では、特にコア数の多い環境で深刻な contention が発生し、この contention によって次のような問題が生じます。

1. ExecutingGraph::updateNode のレイテンシが増加し、クエリパフォーマンスに直接影響します。
2. スピンロックの contention (native\_queued\_spin\_lock\_slowpath) によって過剰な CPU サイクルが浪費され、効率が低下します。
3. CPU 使用率が低下し、並列度とスループットが制限されます。

<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>

`Resize` ノードの分割を無効にするには、この設定を 0 に設定します。これにより、パイプライン生成時に `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 はクエリ実行時にプロジェクション索引の使用を試みます。