max_rows_for_lazy_final
遅延実行 FINAL 最適化で使用する集合の最大行数です。これを超えると、通常の FINAL にフォールバックします。max_rows_in_distinct
DISTINCT 使用時の異なる行の最大数。max_rows_in_join
テーブルの結合時に使用される右側のデータ構造 (通常はハッシュテーブル) 内の行数を制限します。 この設定は、SELECT … JOIN 操作と Join テーブルエンジンに適用されます。 クエリに複数の JOIN が含まれている場合、ClickHouse は各 中間結果に対してこの設定を確認します。これはハッシュベースのすべてのjoin_algorithm に対する厳格な上限であり、制限に
達すると、クエリは
join_overflow_mode に従って throw または break します。
この設定によって JOIN がディスクへスピルすることはありません。その判断は
max_bytes_before_external_join
および
max_bytes_ratio_before_external_join
に委ねられています。
例外は legacy_join_size_limits_trigger_spilling です。これを有効にすると、すでにディスク上で実行されている
JOIN の部分では、この制限は上限ではなく追加のスピルのトリガーとして扱われます。
設定可能な値:
- 正の整数。
0— 行数は無制限。
max_rows_in_set
サブクエリから作成される IN clause 内のデータセットの最大行数。max_rows_in_set_to_optimize_join
結合前に、互いの行セットを使って結合対象のテーブルを絞り込む際のセットの最大サイズです。 設定可能な値:- 0 — 無効。
- 任意の正の整数。
max_rows_to_group_by
集約で取得される一意のキーの最大数です。この設定により、 集約時のメモリ消費を抑えられます。 GROUP BY による集約で、指定した数を超える 行 (一意の GROUP BY キー) が生成された場合の動作は、 既定では ‘group_by_overflow_mode’ のthrow によって決まりますが、
近似 GROUP BY モードに切り替えることもできます。
max_rows_to_read
クエリの実行時にテーブルから読み取ることができる最大行数です。 この制限は、処理される各データ chunk ごとにチェックされ、最も内側の テーブル式にのみ適用されます。また、リモートサーバーから読み取る場合は、 リモートサーバー上でのみチェックされます。max_rows_to_read_leaf
分散クエリの実行時に、リーフノード上のローカルテーブルから読み取れる行数の上限です。 分散クエリでは各分片 (リーフ) に対して複数のサブクエリが発行される場合がありますが、 この制限が適用されるのはリーフノードでの読み取り段階のみであり、 ルートノードで結果をマージする段階では無視されます。 たとえば、あるクラスターが 2 つの分片で構成され、各分片に 100 行を含むテーブルがあるとします。両方のテーブルからすべてのデータを 読み取る分散クエリは、設定max_rows_to_read=150 の場合、合計で
200 行になるため失敗します。一方、max_rows_to_read_leaf=150 を指定した
クエリは成功します。これは、リーフノードでは最大でも 100 行しか
読み取られないためです。
この制限は、処理される各 chunk ごとにチェックされます。
この設定は、
prefer_localhost_replica=1 と併用すると不安定です。max_rows_to_sort
ソート前の行数の上限です。これにより、ソート時のメモリ消費を抑えられます。 ORDER BY の処理で指定された数を超えるレコードを処理する必要がある場合、 その動作はsort_overflow_mode によって決まり、デフォルトでは throw に設定されています。