セッション設定

system.settings テーブルに含まれる設定。

以下の設定はすべて、テーブル system.settings でも利用できます。これらの設定は ソースコード から自動生成されています。

​

add_http_cors_header

HTTP CORS ヘッダーを追加します。

​

additional_result_filter

SELECTクエリの結果に適用される追加のフィルタ式です。 この設定はどのサブクエリにも適用されません。

Example

INSERT INTO table_1 VALUES (1, 'a'), (2, 'bb'), (3, 'ccc'), (4, 'dddd');
SElECT * FROM table_1;

┌─x─┬─y────┐
│ 1 │ a    │
│ 2 │ bb   │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

SELECT *
FROM table_1
SETTINGS additional_result_filter = 'x != 2'

┌─x─┬─y────┐
│ 1 │ a    │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

​

additional_table_filters

指定したテーブルの読み取り後に適用される 追加のフィルタ式です。

例

INSERT INTO table_1 VALUES (1, 'a'), (2, 'bb'), (3, 'ccc'), (4, 'dddd');
SELECT * FROM table_1;

┌─x─┬─y────┐
│ 1 │ a    │
│ 2 │ bb   │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

SELECT *
FROM table_1
SETTINGS additional_table_filters = {'table_1': 'x != 2'}

┌─x─┬─y────┐
│ 1 │ a    │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

​

aggregate_function_input_format

INSERT 操作時の AggregateFunction 入力のフォーマットです。

設定可能な値:

• state — シリアライズされた state を含むバイナリ文字列 (デフォルト) 。AggregateFunction の値をバイナリデータとして受け取る、標準の動作です。
• value — このフォーマットでは、aggregate function の引数の単一の値、または引数が複数ある場合はそれらの Tuple を受け取ります。これらは対応する IDataType または DataTypeTuple を使用してデシリアライズされ、その後集計されて state が形成されます。
• array — このフォーマットでは、上記の value オプションで説明したとおり、値の Array を受け取ります。Array のすべての要素が集計されて state が形成されます。

例

次の structure を持つ table の場合:

CREATE TABLE example (
    user_id UInt64,
    avg_session_length AggregateFunction(avg, UInt32)
);

aggregate_function_input_format = 'value' の場合：

INSERT INTO example FORMAT CSV
123,456

aggregate_function_input_format = 'array' の場合:

INSERT INTO example FORMAT CSV
123,"[456,789,101]"

注: value および array フォーマットは、挿入時に値の生成と集約が必要になるため、デフォルトの state フォーマットよりも低速です。

​

aggregate_functions_null_for_empty

クエリ内のすべての aggregate function を書き換え、-OrNull 接尾辞を付加するかどうかを切り替えます。SQL 標準との互換性のために有効にしてください。 これは、分散クエリで一貫した結果を得るために、クエリの書き換え (count_distinct_implementation 設定と同様) によって実装されています。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

例

次の aggregate function を含むクエリを考えてみましょう:

SELECT SUM(-1), MAX(0) FROM system.one WHERE 0;

aggregate_functions_null_for_empty = 0 の場合、次のようになります。

┌─SUM(-1)─┬─MAX(0)─┐
│       0 │      0 │
└─────────┴────────┘

aggregate_functions_null_for_empty = 1 の場合、結果は次のようになります：

┌─SUMOrNull(-1)─┬─MAXOrNull(0)─┐
│          NULL │         NULL │
└───────────────┴──────────────┘

​

aggregation_in_order_max_block_bytes

主キー順の集約中に蓄積される block の最大サイズ (バイト単位) 。block サイズを小さくすると、集約の最終マージ段階をより並列化しやすくなります。

​

aggregation_memory_efficient_merge_threads

メモリ効率モードで中間の集約結果をマージする際に使用するスレッド数。値が大きいほど、消費メモリも増えます。0 は ‘max_threads’ と同じ意味です。

​

ai_function_credentials

AI 関数がプロバイダの認証情報や設定 (provider、endpoint、model、省略可能な api_key など) に使用する named collection の名前です。空の場合は例外が発生します。

​

ai_function_embedding_max_batch_size

aiEmbed が 1 回の HTTP リクエストで送信するテキストの最大数です。API 呼び出しのオーバーヘッドを減らすため、テキストはこのサイズのバッチにまとめられます。たとえば、一意なテキストが 500 件あり、バッチサイズが 100 の場合、HTTP リクエストは 5 回になります。

​

ai_function_max_api_calls_per_query

AI 関数がクエリごとに発行できる HTTP リクエストの最大数です。無効にするには 0 に設定します。

​

ai_function_max_input_tokens_per_query

1 つのクエリ内における、すべての AI 関数 API 呼び出しの入力 (プロンプト) トークン総数の上限です。これはプロバイダからの応答に基づいて累積的に追跡されます。各呼び出しの入力トークン数は事前にわからないため、この上限は 1 回の呼び出し分の入力トークン数だけ超過する可能性がある点に注意してください。無効にするには 0 に設定します。

この制限は、応答内で usage オブジェクトを返すプロバイダ (OpenAI、Anthropic、vLLM) に対してのみ適用されます。トークン使用量を返さないプロバイダ (特に HuggingFace TEI) ではカウンターが 0 のままになるため、そのような呼び出しの上限を設けるには、代わりに ai_function_max_api_calls_per_query を使用してください。

​

ai_function_max_output_tokens_per_query

1 回のクエリ内における、すべての AI 関数 API 呼び出しでの出力 (completion) トークン総数の上限です。provider からのレスポンスに基づいて累積で追跡されます。各呼び出しの出力トークン数は事前にはわからないため、この上限は 1 回の呼び出し分の出力トークン数だけ超過する場合がある点に注意してください。無効にするには 0 に設定します。

この上限が適用されるのは、レスポンスに usage オブジェクトを含めて返す provider (OpenAI、Anthropic、vLLM) のみです。これは埋め込み関数 (特に aiEmbed) には適用されません。埋め込み関数は出力トークンを生成しないためです。

​

ai_function_max_retries

個々の API リクエストで一時的なエラーが発生した場合の、最大再試行回数です。各再試行では、ai_function_retry_initial_delay_ms を初期値とする指数バックオフを使用します。

​

ai_function_request_timeout_sec

AI 関数が実行する個々の HTTP リクエスト (AI Chat completions および埋め込み API 呼び出し) のタイムアウト時間を秒単位で指定します。リクエストがこの時間内に完了しない場合は失敗と見なされ、ai_function_max_retries に従って再試行されることがあります。

​

ai_function_retry_initial_delay_ms

失敗した AI 関数 API リクエストを初回に再試行するまでの初期遅延時間 (ミリ秒) です。以降の試行では、遅延時間は試行のたびに 2 倍になります (指数バックオフ) 。たとえば、既定の設定では 1000ms、2000ms、4000ms です。

​

ai_function_throw_on_error

true の場合 (デフォルト) 、すべての再試行を使い切っても AI 関数の呼び出しが恒久的に失敗すると、例外を発生させてクエリを中止します。false の場合、失敗した行にはカラム型のデフォルト値 (String の場合は空文字列) が設定され、処理は継続されます。

​

ai_function_throw_on_quota_exceeded

true (デフォルト) の場合、AI 関数のクォータ上限 (ai_function_max_input_tokens_per_query、ai_function_max_output_tokens_per_query、または ai_function_max_api_calls_per_query) を超えると、例外が発生してクエリは中止されます。false の場合、残りの行にはカラムの型のデフォルト値 (String の場合は空文字列) が設定されます。

​

allow_aggregate_partitions_independently

パーティションキーがGROUP BYキーに適している場合、別々のスレッドでパーティションごとに独立して集約できるようにします。パーティション数がコア数に近く、各パーティションのサイズがほぼ同じ場合に効果的です

​

allow_archive_path_syntax

File/S3 エンジン/テーブル関数では、アーカイブの拡張子が正しい場合、’::’ を含むパスを <archive> :: <file> として解析します。

​

allow_asynchronous_read_from_io_pool_for_merge_tree

MergeTree テーブルからの読み取りにバックグラウンド I/O プールを使用します。この設定により、I/O ボトルネックのあるクエリのパフォーマンスが向上する場合があります

​

allow_calculating_subcolumns_sizes_for_merge_tree_reading

有効にすると、ClickHouse は各サブカラムの読み取りに必要なファイルサイズを計算し、タスクサイズおよび block サイズをより適切に算出します。

​

allow_changing_replica_until_first_data_packet

有効な場合、ヘッジドリクエストでは、すでに Progress が発生していても (ただし、receive_data_timeout の timeout の間 Progress が更新されていない場合) 、最初の Data パケットを受信するまでは新しい connection を確立できます。無効な場合は、最初に Progress が発生した時点でレプリカの切り替えを無効にします。

​

allow_create_index_without_type

TYPE を指定しない CREATE INDEX クエリを許可します。このクエリは無視されます。SQL 互換性テスト用です。

​

allow_custom_error_code_in_throwif

関数 throwIf() でカスタムエラーコードを有効にします。true の場合、スローされる例外に想定外のエラーコードが含まれることがあります。

​

allow_ddl

true に設定すると、ユーザーは DDL クエリを実行できます。

​

allow_deprecated_database_ordinary

非推奨のOrdinaryエンジンを使用するデータベースの作成を許可します

​

allow_deprecated_error_prone_window_functions

エラーを起こしやすい非推奨のウィンドウ関数 (neighbor、runningAccumulate、runningDifferenceStartingWithFirstValue、runningDifference) の使用を許可します

​

allow_deprecated_snowflake_conversion_functions

関数 snowflakeToDateTime、snowflakeToDateTime64、dateTimeToSnowflake、dateTime64ToSnowflake は非推奨で、デフォルトで無効になっています。 代わりに、snowflakeIDToDateTime、snowflakeIDToDateTime64、dateTimeToSnowflakeID、dateTime64ToSnowflakeID を使用してください。

非推奨の関数を再び有効にするには (たとえば移行期間中) 、この設定を true にしてください。

​

allow_deprecated_syntax_for_merge_tree

非推奨のエンジン定義構文で *MergeTree テーブルを作成できるようにします

​

allow_distributed_ddl

true に設定すると、ユーザーは分散 DDL クエリを実行できます。

​

allow_drop_detached

ALTER TABLE … DROP DETACHED PART[ITION] … クエリの実行を許可します

​

allow_dynamic_type_in_join_keys

JOIN の結合キーで Dynamic type を使用できるようにします。互換性のために追加されました。Dynamic type を JOIN の結合キーで使用することは、他の型との比較で予期しない結果になる可能性があるため、推奨されません。

​

allow_execute_multiif_columnar

multiIf 関数の列指向実行を許可します

​

allow_experimental_ai_functions

実験的な AI 関数 (例: aiGenerateContent) を有効にします。これらの関数は、AI プロバイダーに対して外部 HTTP リクエストを実行します。

​

allow_experimental_analyzer

別名: enable_analyzer

新しいクエリアナライザを有効にします。

​

allow_experimental_cleanup_old_data_files_compaction

Iceberg compaction 中に古い data files を削除できるようにします。

​

allow_experimental_codecs

true に設定すると、実験的な圧縮コーデックを指定できるようになります (ただし、現時点ではそのようなコーデックはまだ存在しないため、このオプションは何の効果もありません) 。

​

allow_experimental_correlated_subqueries

相関サブクエリを実行できるようにします。

​

allow_experimental_database_glue_catalog

別名: allow_database_glue_catalog

catalog_type = ‘glue’ の実験的なデータベースエンジン DataLakeCatalog の使用を許可します

Cloud でのデフォルト値: 1.

​

allow_experimental_database_hms_catalog

catalog_type = ‘hms’ の実験的なデータベースエンジン DataLakeCatalog を有効にします

​

allow_experimental_database_iceberg

別名: allow_database_iceberg

catalog_type = ‘iceberg’ の実験的なデータベースエンジン DataLakeCatalog の使用を許可します

Cloud でのデフォルト値: 1.

​

allow_experimental_database_materialized_postgresql

Engine=MaterializedPostgreSQL(…) を指定したデータベースの作成を許可します。

​

allow_experimental_database_paimon_rest_catalog

catalog_type = ‘paimon_rest’ の実験的なデータベースエンジン DataLakeCatalog を有効にします

​

allow_experimental_database_unity_catalog

別名: allow_database_unity_catalog

catalog_type = ‘unity’ の実験的なデータベースエンジン DataLakeCatalog を有効にします

Cloud でのデフォルト値: 1.

​

allow_experimental_delta_kernel_rs

実験的な delta-kernel-rs 実装を有効にします。

​

allow_experimental_delta_lake_writes

delta-kernel による書き込み機能を有効にします。

​

allow_experimental_expire_snapshots

実験的な Iceberg コマンド ALTER TABLE ... EXECUTE expire_snapshots を実行できるようにします。

​

allow_experimental_funnel_functions

ファネル分析用の実験的な関数を有効にします。

​

allow_experimental_geo_types_in_iceberg

Iceberg の geometry および geography フィールド型を、ClickHouse の Geometry (Variant) 型としてパースできるようにします。

​

allow_experimental_hash_functions

実験的なハッシュ関数を有効にする

​

allow_experimental_iceberg_compaction

Iceberg テーブルに対して ‘OPTIMIZE’ を明示的に実行できるようにします。

​

allow_experimental_join_right_table_sorting

true に設定され、join_to_sort_minimum_perkey_rows と join_to_sort_maximum_table_rows の条件が満たされている場合、LEFT または INNER のハッシュ結合のパフォーマンスを向上させるため、右テーブルをキー順に並べ替えます。

​

allow_experimental_json_lazy_type_hints

JSON型に対する実験的な遅延型ヒントを有効にします。この機能では、型ヒントの評価を遅延させることで、JSON型変換を最適化できます。

​

allow_experimental_kafka_offsets_storage_in_keeper

Kafka 関連のオフセットを ClickHouse Keeper に保存する実験的機能を有効にします。有効にすると、ClickHouse Keeper の path とレプリカ名を Kafka テーブルエンジンに指定できます。その結果、通常の Kafka エンジンの代わりに、コミット済みオフセットを主に ClickHouse Keeper に保存する新しい種類のストレージエンジンが使用されます

​

allow_experimental_kusto_dialect

SQL の代替となる Kusto Query Language (KQL) を有効にします。

​

allow_experimental_materialized_postgresql_table

MaterializedPostgreSQLテーブルエンジンを使用できるようにします。この機能は実験的であるため、デフォルトでは無効になっています

​

allow_experimental_nlp_functions

自然言語処理向けの実験的な関数を有効にします。

​

allow_experimental_nullable_tuple_type

別名: enable_nullable_tuple_type

テーブルで Nullable Tuple カラムを作成できるようにします。

この設定は、抽出された Tuple のサブカラムを Nullable にできるかどうかは制御しません (たとえば、Dynamic、Variant、JSON、または Tuple カラムから抽出されたもの) 。 抽出された Tuple のサブカラムを Nullable にできるかどうかを制御するには、allow_nullable_tuple_in_extracted_subcolumns を使用してください。

​

allow_experimental_object_storage_queue_hive_partitioning

S3Queue/AzureQueue エンジンで Hive パーティション化を使用できるようにします

​

allow_experimental_paimon_storage_engine

Paimon* テーブルエンジンでテーブルを作成できるようにします。

​

allow_experimental_parallel_reading_from_replicas

別名: enable_parallel_replicas

SELECT クエリの実行時に、各分片から最大 max_parallel_replicas 個のレプリカを使用します。読み取りは並列化され、動的に調整されます。0 - 無効、1 - 有効 (障害時は自動的に無効化) 、2 - 有効 (障害時に例外をスロー)

​

allow_experimental_polyglot_dialect

polyglot SQL トランスパイラを有効にします。30 種類以上の SQL 方言 (MySQL、PostgreSQL、SQLite、Snowflake、DuckDB など) の SQL を ClickHouse SQL に変換します。

​

allow_experimental_prql_dialect

PRQL (SQL の代替) を有効にします。

​

allow_experimental_text_index_lazy_apply

true に設定すると、テキスト索引クエリで遅延ポスティングリスト適用モードを使用できるようになります。

​

allow_experimental_time_series_aggregate_functions

別名: allow_experimental_ts_to_grid_aggregate_function

Prometheus ライクな時系列のリサンプリング、rate、delta 計算のための実験的な timeSeries* 集約関数。

​

allow_experimental_time_series_table

TimeSeries テーブルエンジンを使用するテーブルの作成を許可します。設定可能な値:

• 0 — TimeSeries テーブルエンジンは無効です。
• 1 — TimeSeries テーブルエンジンは有効です。

​

allow_experimental_unique_key

MergeTree ファミリーのエンジンを使用するテーブルで UNIQUE KEY 句を指定して作成できるようにします。

​

allow_experimental_window_view

WINDOW VIEW を有効にします。まだ十分に実用段階には達していません。

​

allow_experimental_ytsaurus_dictionary_source

YTsaurus とのインテグレーション用の実験的な Dictionary ソース。

​

allow_experimental_ytsaurus_table_engine

YTsaurusとのインテグレーション向けの実験的なテーブルエンジンです。

​

allow_experimental_ytsaurus_table_function

YTsaurus とのインテグレーションのための実験的なテーブルエンジン。

​

allow_fuzz_query_functions

クエリ文字列にランダムな AST のミューテーションを適用する fuzzQuery 関数を有効にします。

​

allow_general_join_planning

より複雑な条件を扱える、より汎用的な JOIN 計画アルゴリズムを許可しますが、これはハッシュ結合でのみ機能します。ハッシュ結合が有効になっていない場合は、この設定値にかかわらず、通常の JOIN 計画アルゴリズムが使用されます。

​

allow_get_client_http_header

現在のHTTPリクエストのヘッダーの値を取得できる関数 getClientHTTPHeader の使用を許可します。Cookie など一部のヘッダーには機密情報が含まれる可能性があるため、セキュリティ上の理由からデフォルトでは有効になっていません。なお、X-ClickHouse-* および Authentication ヘッダーは常に制限されており、この関数では取得できません。

​

allow_hyperscan

Hyperscan ライブラリを使用する関数を許可します。コンパイル時間が長くなりすぎたり、リソースを過剰に消費したりするのを避けるには、無効にしてください。

​

allow_iceberg_remove_orphan_files

Icebergテーブルに対して ‘ALTER TABLE … EXECUTE remove_orphan_files()’ を使用できるようにします。

​

allow_insert_into_iceberg

別名: allow_experimental_insert_into_iceberg

Iceberg に対する insert クエリの実行を許可します。

​

allow_introspection_functions

クエリのプロファイリングに対するイントロスペクション関数の有効/無効を切り替えます。

設定可能な値:

• 1 — イントロスペクション関数が有効です。
• 0 — イントロスペクション関数が無効です。

関連項目

• サンプリングクエリプロファイラ
• システムテーブル trace_log

​

allow_key_condition_coalesce_rewrite

この設定を有効にすると、coalesce または ifNull を含む WHERE/PREWHERE 述語に対して、MergeTree の主キーおよびスキップ索引で granule を絞り込めるようになります。この設定が無効な場合、そのような述語は索引解析では内容を判別できないため絞り込みに使われず、一致しない granule も読み込まれます。影響があるのは読み込まれる granule だけで、クエリ結果は変わりません。行のフィルタリングには引き続き元の述語が使われるためです。

索引解析の前に、次の 2 種類の述語の shape が書き換えられます:

• coalesce/ifNull に対する比較 (たとえば coalesce(a, b) = 5) は、各引数の索引で絞り込めるよう論理和に書き換えられます: a = 5 OR (a IS NULL AND b = 5)。引数がさらに多い場合も同様に拡張されます。
• 条件として直接使われる、偽値 (ゼロ) の定数をデフォルト値に持つ coalesce/ifNull (たとえば ifNull(a = 5, 0) や coalesce(a = 5, 0)) は、内部の述語 a = 5 にアンラップされます。このような wrapper は、内部述語の三値論理の結果を確定したブール値に畳み込みます (NULL は false に対応付けられます) 。

​

allow_limit_by_partitions_independently

パーティション式が LIMIT BY のカラムの決定論的関数である場合、パーティションごとに独立した LIMIT BY の評価を別々のスレッドで有効にします。

​

allow_materialized_view_with_bad_select

存在しないテーブルまたはカラムを参照する SELECT クエリを含む CREATE MATERIALIZED VIEW を許可します。ただし、構文としては有効である必要があります。リフレッシュ可能な MV には適用されません。また、MV のスキーマを SELECT クエリから推論する必要がある場合 (つまり、CREATE にカラムリストがなく、かつ TO テーブルもない場合) にも適用されません。ソーステーブルより先に MV を作成するために使用できます。

​

allow_named_collection_override_by_default

デフォルトで、named collections のフィールドのオーバーライドを許可します。

​

allow_non_metadata_alters

テーブルのメタデータだけでなく、ディスク上のデータにも影響する ALTER の実行を許可します

​

allow_nonconst_timezone_arguments

toTimeZone()、fromUnixTimestamp*()、snowflakeToDateTime*() などの一部の時刻関連関数で、非定数のタイムゾーン引数を許可します。 この設定は、互換性上の理由からのみ存在します。ClickHouse では、タイムゾーンはデータ型、より正確にはカラムのプロパティです。 この設定を有効にすると、1 つのカラム内の異なる値にそれぞれ異なるタイムゾーンを設定できるかのような誤解を招きます。 したがって、この設定は有効にしないでください。

​

allow_nondeterministic_mutations

dictGet のような非決定論的関数を、レプリケートテーブルに対する mutation で使用できるようにするユーザーレベルの設定です。

たとえば、辞書はノード間で同期が取れていない場合があるため、そこから値を取得する mutation は、デフォルトではレプリケートテーブルで許可されていません。この設定を有効にすると、そのような動作を許可できますが、使用するデータがすべてのノードで同期されていることを保証する責任はユーザーにあります。

例

<profiles>
    <default>
        <allow_nondeterministic_mutations>1</allow_nondeterministic_mutations>

        <!-- ... -->
    </default>

    <!-- ... -->

</profiles>

​

allow_nondeterministic_optimize_skip_unused_shards

分片キーで、非決定論的な関数 (rand や dictGet など。後者は更新時にいくつか注意点があります) の使用を許可します。

設定可能な値:

• 0 — 不可。
• 1 — 可。

​

allow_nullable_tuple_in_extracted_subcolumns

Tuple(...) 型の抽出サブカラムを Nullable(Tuple(...)) 型として扱えるかどうかを制御します。

• false: Tuple(...) を返し、サブカラムが存在しない行ではデフォルトのタプル値を使用します。
• true: Nullable(Tuple(...)) を返し、サブカラムが存在しない行では NULL を使用します。

この設定で制御されるのは、抽出サブカラムの動作のみです。 テーブル内で Nullable(Tuple(...)) カラムを作成できるかどうかは制御しません。こちらは enable_nullable_tuple_type で制御されます。

ClickHouse は、サーバー起動時に読み込まれたこの設定値を使用します。 SET またはクエリレベルの SETTINGS で変更しても、抽出サブカラムの動作は変わりません。 抽出サブカラムの動作を変更するには、起動プロファイル設定 (たとえば users.xml) 内の allow_nullable_tuple_in_extracted_subcolumns を更新し、サーバーを再起動してください。

​

allow_prefetched_read_pool_for_local_filesystem

すべてのパーツがローカルファイルシステム上にある場合は、プリフェッチ用のスレッドプールを優先します

​

allow_prefetched_read_pool_for_remote_filesystem

すべてのパーツがリモートファイルシステム上にある場合は、先読み用スレッドプールを優先します

​

allow_push_predicate_ast_for_distributed_subqueries

analyzer が有効な場合に、分散サブクエリに対する AST レベルでの述語プッシュダウンを許可します

​

allow_push_predicate_when_subquery_contains_with

サブクエリにWITH句が含まれている場合に、述語プッシュダウンを許可します

​

allow_rank_dense_rank_arguments

後方互換性のために、RANK および DENSE_RANK ウィンドウ関数に引数を渡せるようにします。

SQL 標準では、RANK と DENSE_RANK は引数を取りません。これらは OVER (ORDER BY ...) ウィンドウのみに基づいて行の順位を付けます。ClickHouse 26.5 より前のバージョンでは、 RANK(x) OVER (...) のようなクエリでも引数が黙って受け入れられ、無視されていました。これにより、 ユーザーの混乱を招いていました (引数が見えているため順位付けに影響しているように見えますが、実際には影響しません) 。

この設定が false (デフォルト) の場合、RANK と DENSE_RANK は引数を受け付けず、 NUMBER_OF_ARGUMENTS_DOESNT_MATCH を返します。true に設定すると、従来の寛容な動作が 復元され、26.5 より前と同様に引数は黙って無視されます。

​

allow_reorder_prewhere_conditions

条件を WHERE から PREWHERE に移動する際、フィルタリングを最適化できるよう並べ替えを許可します

​

allow_settings_after_format_in_insert

INSERT クエリで、FORMAT の後に SETTINGS を許可するかどうかを制御します。ただし、SETTINGS の一部が値として解釈される可能性があるため、使用は推奨されません。

Example:

INSERT INTO FUNCTION null('foo String') SETTINGS max_threads=1 VALUES ('bar');

ただし、次のクエリは allow_settings_after_format_in_insert が有効な場合にのみ動作します。

SET allow_settings_after_format_in_insert=1;
INSERT INTO FUNCTION null('foo String') VALUES ('bar') SETTINGS max_threads=1;

設定可能な値:

• 0 — 不可。
• 1 — 可。

この設定は、ユースケースで古い構文に依存している場合にのみ、後方互換性のために使用してください。

​

allow_simdjson

AVX2 命令が利用可能な場合に、JSON* 関数で simdjson ライブラリを使用できるようにします。無効にすると、rapidjson が使用されます。

​

allow_special_serialization_kinds_in_output_formats

Sparse や Replicated のような特殊なシリアライゼーション種別を持つカラムを、フルカラム表現に変換せずに出力できるようにします。 これにより、フォーマット時の不要なデータコピーを避けられます。

​

allow_statistics

別名: allow_experimental_statistics

カラムに statistics を設定して定義し、statistics を操作できるようにします。

​

allow_statistics_optimize

別名: allow_statistic_optimize

統計情報を使用してクエリを最適化することを許可します

​

allow_suspicious_codecs

true に設定すると、意味のない圧縮コーデックを指定できるようになります。

​

allow_suspicious_fixed_string_types

CREATE TABLE 文で、n > 256 の FixedString(n) 型のカラムを作成できるようにします。長さが 256 以上の FixedString は不自然であり、多くの場合は誤用を示しています

​

allow_suspicious_indices

同一の式を持つプライマリ/セカンダリ索引およびソートキーを拒否します

​

allow_suspicious_low_cardinality_types

8 バイト以下の固定サイズを持つデータ型、つまり数値データ型および FixedString(8_bytes_or_less) で LowCardinality を使用することを許可または制限します。

固定長でサイズの小さい値に LowCardinality を使用しても、通常は非効率です。これは、ClickHouse が各行に対して数値索引を格納するためです。その結果、次のような影響が生じる可能性があります。

• ディスク使用量が増加することがあります。
• Dictionary のサイズによっては、RAM 使用量が増えることがあります。
• 追加の符号化/復号化処理により、一部の関数の動作が遅くなることがあります。

上記の理由により、MergeTree-engine テーブルではマージ時間が長くなる可能性があります。

設定可能な値:

• 1 — LowCardinality の使用は制限されません。
• 0 — LowCardinality の使用は制限されます。

​

allow_suspicious_primary_key

MergeTree の疑わしい PRIMARY KEY/ORDER BY (例: SimpleAggregateFunction) を許可します。

​

allow_suspicious_ttl_expressions

テーブルのどのカラムにも依存しない有効期限 (TTL) 式を拒否します。これは多くの場合、ユーザーの指定ミスを示します。

​

allow_suspicious_types_in_group_by

GROUP BY キーで Variant 型および Dynamic 型の使用を許可または禁止します。

​

allow_suspicious_types_in_order_by

ORDER BY キーでの Variant 型および Dynamic 型の使用を許可または制限します。

​

allow_suspicious_variant_types

CREATE TABLE 文で、類似した Variant 型 (たとえば、異なる数値型や日付型) を含む Variant 型を指定できるようにします。この設定を有効にすると、類似した型の値を扱う際にあいまいさが生じる可能性があります。

​

allow_unrestricted_reads_from_keeper

system.zookeeper テーブルからの無制限な (path に条件を付けない) 読み取りを許可します。便利な場合もありますが、ZooKeeper に対して安全ではありません。

​

alter_move_to_space_execute_async

ALTER TABLE MOVE … TO [DISK|VOLUME] を非同期に実行します

​

alter_partition_verbose_result

パーティションおよびパーツに対する操作が正常に適用されたパーツに関する情報の表示を有効または無効にします。 ATTACH PARTITION|PART および FREEZE PARTITION に適用されます。

設定可能な値:

• 0 — 詳細表示を無効にします。
• 1 — 詳細表示を有効にします。

例

CREATE TABLE test(a Int64, d Date, s String) ENGINE = MergeTree PARTITION BY toYYYYMDECLARE(d) ORDER BY a;
INSERT INTO test VALUES(1, '2021-01-01', '');
INSERT INTO test VALUES(1, '2021-01-01', '');
ALTER TABLE test DETACH PARTITION ID '202101';

ALTER TABLE test ATTACH PARTITION ID '202101' SETTINGS alter_partition_verbose_result = 1;

┌─command_type─────┬─partition_id─┬─part_name────┬─old_part_name─┐
│ ATTACH PARTITION │ 202101       │ 202101_7_7_0 │ 202101_5_5_0  │
│ ATTACH PARTITION │ 202101       │ 202101_8_8_0 │ 202101_6_6_0  │
└──────────────────┴──────────────┴──────────────┴───────────────┘

ALTER TABLE test FREEZE SETTINGS alter_partition_verbose_result = 1;

┌─command_type─┬─partition_id─┬─part_name────┬─backup_name─┬─backup_path───────────────────┬─part_backup_path────────────────────────────────────────────┐
│ FREEZE ALL   │ 202101       │ 202101_7_7_0 │ 8           │ /var/lib/clickhouse/shadow/8/ │ /var/lib/clickhouse/shadow/8/data/default/test/202101_7_7_0 │
│ FREEZE ALL   │ 202101       │ 202101_8_8_0 │ 8           │ /var/lib/clickhouse/shadow/8/ │ /var/lib/clickhouse/shadow/8/data/default/test/202101_8_8_0 │
└──────────────┴──────────────┴──────────────┴─────────────┴───────────────────────────────┴─────────────────────────────────────────────────────────────┘

​

alter_sync

別名: replication_alter_partitions_sync

ALTER、OPTIMIZE または TRUNCATE クエリによってレプリカ上で実行されるアクションについて、どのように待機するかを指定できます。

設定可能な値:

• 0 — 待機しません。
• 1 — 自身の実行完了を待機します。
• 2 — すべてのレプリカの実行完了を待機します。
• 3 - アクティブなレプリカの実行完了のみ待機します。

Cloud でのデフォルト値: 0。

alter_sync は Replicated テーブルおよび SharedMergeTree テーブルにのみ適用され、Replicated テーブルでも Shared テーブルでもないテーブルに対する alter には効果がありません。

​

alter_update_mode

UPDATE コマンドを含む ALTER クエリに対するモードです。

設定可能な値:

• heavy - 通常のミューテーションを実行します。
• lightweight - 可能であれば論理更新を実行し、そうでない場合は通常のミューテーションを実行します。
• lightweight_force - 可能であれば論理更新を実行し、そうでない場合は例外をスローします。

​

analyze_index_with_space_filling_curves

テーブルの索引に空間充填曲線が含まれている場合、たとえば ORDER BY mortonEncode(x, y) または ORDER BY hilbertEncode(x, y) で、クエリにその引数に対する条件 (たとえば x >= 10 AND x <= 20 AND y >= 20 AND y <= 30) があると、索引解析に空間充填曲線を使用します。

​

analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested

nested に複合識別子を追加できるようにします。クエリ結果が変わるため、これは互換性維持のための設定です。無効にすると、SELECT a.b.c FROM table ARRAY JOIN a は動作せず、SELECT a FROM table でも a.b.c カラムは Nested a の結果に含まれません。

​

analyzer_compatibility_join_using_top_level_identifier

JOIN USING 内の識別子を射影から解決するよう強制します (たとえば、SELECT a + 1 AS b FROM t1 JOIN t2 USING (b) では、結合は t1.b = t2.b ではなく、t1.a + 1 = t2.b によって実行されます) 。

​

analyzer_compatibility_prefer_alias_over_subcolumn

b.id のような複合識別子が、別名 b を持つテーブルのカラム id を指す場合と、別のカラムの Tuple サブカラム b.id を指す場合の両方があり得るときは、別名プレフィックスとしての解釈 (b のカラム id) を優先します。デフォルトでは、新しいアナライザはサブカラムを優先します。従来のアナライザの名前解決に合わせるには、これを有効にしてください。

​

analyzer_inline_views

有効にすると、アナライザは通常の (非マテリアライズドでパラメータ化されていない) ビューをその定義サブクエリに置き換え、述語のプッシュダウンやカラムプルーニングなどの境界をまたいだ最適化を可能にします。

​

any_join_distinct_right_table_keys

ANY INNER|LEFT JOIN 演算で、従来の ClickHouse server の動作を有効にします。

この設定は、ユースケースが従来の JOIN の動作に依存している場合に限り、後方互換性のために使用してください。

従来の動作が有効な場合:

• ClickHouse は、左から右へのテーブルキーの多対一マッピングのロジックを使用するため、t1 ANY LEFT JOIN t2 と t2 ANY RIGHT JOIN t1 の結果は一致しません。
• ANY INNER JOIN の結果には、SEMI LEFT JOIN と同様に、左テーブルのすべての行が含まれます。

従来の動作が無効な場合:

• ClickHouse は、ANY RIGHT JOIN で一対多のキーマッピングを行うロジックを使用するため、t1 ANY LEFT JOIN t2 と t2 ANY RIGHT JOIN t1 の結果は同一になります。
• ANY INNER JOIN の結果には、左テーブルと右テーブルの両方から、キーごとに 1 行が含まれます。

設定可能な値:

• 0 — 従来の動作は無効です。
• 1 — 従来の動作は有効です。

関連項目:

• JOIN strictness

​

apply_deleted_mask

論理削除された行を除外するフィルタリングを有効にします。無効にすると、クエリでそれらの行を読み取れるようになります。これは、デバッグや「削除の取り消し」のシナリオで役立ちます

​

apply_mutations_on_fly

true の場合、データパートにまだ materialized されていない mutations (UPDATE および DELETE) は、SELECT 時に適用されます。

​

apply_patch_parts

true の場合、パッチパート (論理更新を表す) は SELECT 時に適用されます。

​

apply_patch_parts_join_cache_buckets

Join モードでパッチパートを適用する際に使用する一時 cache 内のバケット数。

​

apply_prewhere_after_final

有効にすると、ReplacingMergeTree および同様のエンジンでは、PREWHERE 条件が FINAL 処理の後に適用されます。 これは、PREWHERE が重複した行ごとに値が異なる可能性のあるカラムを参照しており、 フィルタリングする前に FINAL で採用される行を確定させたい場合に便利です。無効の場合、PREWHERE は読み取り時に適用されます。 注: apply_row_level_security_after_final が有効で、かつ行ポリシーがソートキー以外のカラムを使用している場合、正しい実行順序を保つために PREWHERE も 後ろに延期されます (行ポリシーは PREWHERE より前に適用される必要があります) 。

​

apply_row_policy_after_final

有効にすると、行ポリシーと PREWHERE は *MergeTree テーブルでの FINAL 処理後に適用されます。 (特に ReplacingMergeTree の場合) 無効にすると、行ポリシーは FINAL の前に適用されるため、ポリシーによって ReplacingMergeTree や同様のエンジンで重複排除に使われるべき行が除外されると、結果が変わる可能性があります。

行ポリシーの式が ORDER BY 内のカラムのみに依存している場合は、最適化のため、それでも FINAL の前に適用されます。 このようなフィルタリングは重複排除の結果に影響しないためです。

設定可能な値:

• 0 — 行ポリシーと PREWHERE は FINAL の前に適用されます (デフォルト) 。
• 1 — 行ポリシーと PREWHERE は FINAL の後に適用されます。

​

apply_settings_from_server

クライアントがサーバーから設定を受け入れるかどうかを指定します。

これはクライアント側で実行される操作にのみ影響し、特に INSERT の入力データのパースとクエリ結果のフォーマットに関係します。クエリ実行の大部分はサーバー上で行われるため、この設定の影響は受けません。

通常、この設定はクライアント経由 (クライアントのコマンドライン引数、SET クエリ、または SELECT クエリの SETTINGS セクション) ではなく、ユーザープロファイル (users.xml または ALTER USER などのクエリ) で設定する必要があります。クライアント経由では false に変更できますが、true には変更できません (ユーザープロファイルで apply_settings_from_server = false になっている場合、サーバーは設定を送信しないためです) 。

なお、当初 (24.12) にはサーバー setting (send_settings_to_client) がありましたが、使いやすさの向上のため、後にこの client setting に置き換えられました。

​

archive_adaptive_buffer_max_size_bytes

アーカイブファイル (たとえば tar アーカイブ) への書き込み時に使用されるアダプティブバッファの最大サイズを制限します

​

arrow_flight_request_descriptor_type

Arrow Flight リクエストで使用するディスクリプタの種類です。‘path’ はデータセット名を path ディスクリプタとして送信します。‘command’ は SQL クエリを command ディスクリプタとして送信します (Dremio では必須) 。

設定可能な値:

• ‘path’ — FlightDescriptor::Path を使用します (デフォルト。ほとんどの Arrow Flight サーバーで動作します)
• ‘command’ — SELECT クエリを指定して FlightDescriptor::Command を使用します (Dremio では必須)

​

ast_fuzzer_any_query

false (デフォルト) の場合、サーバー側の AST fuzzer (ast_fuzzer_runs で制御) は、読み取り専用クエリ (SELECT、EXPLAIN、SHOW、DESCRIBE、EXISTS) のみをファジングします。true の場合は、DDL や INSERT を含むすべてのクエリタイプがファジングされます。

​

ast_fuzzer_runs

通常のクエリを実行するたびに、その後でランダム化されたクエリを実行し、結果を破棄するサーバー側 AST fuzzer を有効にします。

• 0: 無効 (デフォルト) 。
• 0 より大きく 1 未満の値: ファズ化クエリを 1 件実行する確率。
• 1 以上の値: 通常のクエリ 1 件ごとに実行するファズ化クエリ数。

この fuzzer は、すべてのセッションにまたがるすべてのクエリから AST フラグメントを蓄積し、時間の経過とともにより興味深いミューテーションを生成します。失敗したファズ化クエリは黙って破棄され、結果がクライアントに返されることはありません。

​

asterisk_include_alias_columns

ワイルドカードクエリ (SELECT *) に ALIAS カラムを含めるかどうかを指定します。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

asterisk_include_materialized_columns

ワイルドカードクエリ (SELECT *) に MATERIALIZED カラムを含めます。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

asterisk_include_virtual_columns

ワイルドカードクエリ (SELECT *) に仮想カラムを含めるかどうかを指定します。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

async_insert

true の場合、INSERT クエリのデータはキューに保存され、後でバックグラウンドでテーブルにフラッシュされます。wait_for_async_insert が false の場合、INSERT クエリはほぼ即座に処理され、そうでない場合はデータがテーブルにフラッシュされるまでクライアントは待機します

​

async_insert_busy_timeout_decrease_rate

適応型非同期挿入タイムアウトの短縮時に用いられる指数関数的な増加率

​

async_insert_busy_timeout_increase_rate

適応型非同期挿入タイムアウトが増加する際の指数関数的な増加率

​

async_insert_busy_timeout_max_ms

別名: async_insert_busy_timeout_ms

最初のデータが到着してから、クエリごとに収集されたデータをダンプするまでの最大待機時間です。

Cloud でのデフォルト値: 1000 (1s).

​

async_insert_busy_timeout_min_ms

async_insert_use_adaptive_busy_timeout によって自動調整が有効になっている場合、最初のデータが到着してから、クエリごとに収集されたデータを書き出すまでの最小待機時間です。これは適応アルゴリズムの初期値としても機能します

​

async_insert_deduplicate

レプリケートテーブルに対する非同期 INSERT クエリで、挿入されるブロックの重複排除を行うかどうかを指定します

​

async_insert_max_data_size

挿入される前にクエリごとに収集される未解析データの最大サイズ (バイト単位)

Cloud でのデフォルト値: 104857600 (100 MiB).

​

async_insert_max_query_number

挿入が実行されるまでに蓄積される insert クエリの最大数。 設定 async_insert_deduplicate が 1 の場合にのみ有効です。

​

async_insert_poll_timeout_ms

非同期挿入キューからデータをポーリングする際のタイムアウト

​

async_insert_use_adaptive_busy_timeout

true に設定すると、非同期挿入に適応型のビジータイムアウトを使用します

​

async_query_sending_for_remote

リモートクエリの実行時に、接続の作成とクエリの送信を非同期で行います。

デフォルトで有効です。

​

async_socket_for_remote

リモートクエリの実行中に、ソケットからの非同期読み取りを有効にします。

デフォルトで有効です。

​

automatic_parallel_replicas_min_bytes_per_replica

並列レプリカを自動的に有効にするための、レプリカごとの読み取りバイト数のしきい値です (automatic_parallel_replicas_mode=1 の場合にのみ適用されます) 。0 はしきい値がないことを意味します。 読み取る総バイト数は、収集された統計に基づいて推定されます。

​

automatic_parallel_replicas_mode

収集した統計に基づいて、並列レプリカを使用した実行へ自動的に切り替える機能を有効にします。enable_analyzer = 1、enable_parallel_replicas != 0、parallel_replicas_local_plan = 1 が必要で、さらに cluster_for_parallel_replicas を指定する必要があります。 0 - 無効、1 - 有効、2 - 統計の収集のみ有効 (並列レプリカを使用した実行への切り替えは無効) 。

​

azure_allow_parallel_part_upload

Azure のマルチパートアップロードに複数のスレッドを使用します。

​

azure_check_objects_after_upload

Azure Blob Storage 内の各アップロード済みオブジェクトを確認し、アップロードが成功したことを確かめます

​

azure_connect_timeout_ms

Azure ディスクのホストへの接続タイムアウト。

​

azure_create_new_file_on_insert

Azureエンジンのテーブルで、insertのたびに新しいファイルを作成するかどうかを設定します

​

azure_ignore_file_doesnt_exist

特定のキーの読み取り時に、ファイルが存在しない場合はそれを無視します。

設定可能な値:

• 1 — SELECT は空の結果を返します。
• 0 — SELECT は例外をスローします。

​

azure_list_object_keys_size

ListObject リクエストで一度に返されるファイルの最大数

​

azure_max_blocks_in_multipart_upload

Azure のマルチパートアップロードにおけるブロックの最大数。

​

azure_max_get_burst

1 秒あたりのリクエスト数の制限に達するまでに、同時に発行できるリクエストの最大数。デフォルト値 (0) は azure_max_get_rps と同じです

​

azure_max_get_rps

スロットリングが適用される前の、Azure GET リクエストの毎秒あたりの上限数。0 は無制限を意味します。

​

azure_max_inflight_parts_for_one_file

マルチパートアップロードリクエスト内で同時に読み込めるパーツの最大数です。0 は無制限を意味します。

​

azure_max_put_burst

1 秒あたりのリクエスト数制限に達するまでに同時に発行できるリクエストの最大数。デフォルト値 (0) は azure_max_put_rps と同じです

​

azure_max_put_rps

スロットリングが発生する前の、Azure の PUT リクエストの 1 秒あたりのレート上限です。0 は無制限を意味します。

​

azure_max_redirects

許可される Azure リダイレクトの最大ホップ数。

​

azure_max_single_part_copy_size

Azure blob storage への単一パートコピーでコピー可能なオブジェクトの最大サイズ。

​

azure_max_single_part_upload_size

Azure blob storage へのシングルパートアップロードでアップロードできるオブジェクトの最大サイズ。

​

azure_max_single_read_retries

Azure blob storage の単一読み取り時における最大再試行回数。

​

azure_max_unexpected_write_error_retries

Azure blob storage への書き込み中に想定外のエラーが発生した場合の最大再試行回数

​

azure_max_upload_part_size

Azure blob storage へのマルチパートアップロード時にアップロードする part の最大サイズ。

​

azure_min_upload_part_size

Azure Blob Storage へのマルチパートアップロード時にアップロードするパートの最小サイズ。

​

azure_request_timeout_ms

Azure とのデータ送受信時のアイドルタイムアウトです。TCP の単一の読み取りまたは書き込み呼び出しがこの時間を超えてブロックされると失敗します。

​

azure_sdk_max_retries

Azure SDK における最大再試行回数

​

azure_sdk_retry_initial_backoff_ms

Azure SDK における再試行間の最小バックオフ

​

azure_sdk_retry_max_backoff_ms

Azure SDK での再試行間の最大バックオフ

​

azure_skip_empty_files

S3 engine で空ファイルのスキップを有効または無効にします。

設定可能な値:

• 0 — 空ファイルが要求されたフォーマットに対応していない場合、SELECT は例外をスローします。
• 1 — 空ファイルに対して SELECT は空の結果を返します。

​

azure_strict_upload_part_size

Azure Blob Storage へのマルチパートアップロード時にアップロードするパートの正確なサイズ。

​

azure_throw_on_zero_files_match

glob 展開ルールに基づいて一致するファイルが 0 個の場合、エラーを発生させます。

設定可能な値:

• 1 — SELECT は例外をスローします。
• 0 — SELECT は空の結果を返します。

​

azure_truncate_on_insert

Azure engine テーブルで、insert の前に TRUNCATE を実行するかどうかを有効または無効にします。

​

azure_upload_part_size_multiply_factor

Azure blob storage への1回の書き込みで azure_multiply_parts_count_threshold 個のパーツがアップロードされるたびに、azure_min_upload_part_size にこの係数を乗じます。

​

azure_upload_part_size_multiply_parts_count_threshold

この数のパーツが Azure blob storage にアップロードされるたびに、azure_min_upload_part_size は azure_upload_part_size_multiply_factor 倍になります。

​

azure_use_adaptive_timeouts

true に設定すると、すべての Azure リクエストで、最初の 2 回の試行は送信および受信タイムアウトを短くして行われます。 false に設定すると、すべての試行が同じタイムアウトで行われます。

​

backup_restore_batch_size_for_keeper_multi

バックアップまたは復元時に [Zoo]Keeper へのマルチリクエストで使用するバッチの最大サイズ

​

backup_restore_batch_size_for_keeper_multiread

バックアップまたは復元時に [Zoo]Keeper へのマルチリードリクエストで使用するバッチの最大サイズ

​

backup_restore_failure_after_host_disconnected_for_seconds

BACKUP ON CLUSTER または RESTORE ON CLUSTER の実行中に、あるホストがこの時間内に ZooKeeper 内の一時的な ‘alive’ ノードを再作成できない場合、バックアップまたは復元全体が失敗と見なされます。 この値は、障害発生後にホストが ZooKeeper に再接続するまでの妥当な時間よりも長くする必要があります。 0 は無制限を意味します。

​

backup_restore_finish_timeout_after_error_sec

現在の BACKUP ON CLUSTER または RESTORE ON CLUSTER 操作で、イニシエーターが他のホストの ‘error’ ノードへの反応と作業停止を待機する時間。

​

backup_restore_keeper_fault_injection_probability

バックアップまたは復元中に Keeper リクエストが失敗するおおよその確率です。有効な値の範囲は [0.0f, 1.0f] です

​

backup_restore_keeper_fault_injection_seed

0 - ランダムシード、それ以外は設定値

​

backup_restore_keeper_max_retries

BACKUP または RESTORE の実行中に行われる [Zoo]Keeper 操作の最大再試行回数。 一時的な [Zoo]Keeper 障害によって処理全体が失敗しないよう、十分に大きな値にする必要があります。

​

backup_restore_keeper_max_retries_while_handling_error

BACKUP ON CLUSTER または RESTORE ON CLUSTER のエラー処理中における [Zoo]Keeper 操作の最大再試行回数。

​

backup_restore_keeper_max_retries_while_initializing

BACKUP ON CLUSTER または RESTORE ON CLUSTER の初期化中における [Zoo]Keeper 操作の最大再試行回数。

​

backup_restore_keeper_retry_initial_backoff_ms

バックアップまたは復元時の [Zoo]Keeper 操作に対する初期バックオフのタイムアウト

​

backup_restore_keeper_retry_max_backoff_ms

バックアップまたは復元時の [Zoo]Keeper 操作における最大 backoff timeout

Cloud でのデフォルト値: 60000.

​

backup_restore_keeper_value_max_size

バックアップ時の[Zoo]Keeperノードのデータの最大サイズ

​

backup_restore_s3_retry_attempts

Aws::Client::RetryStrategy の設定。Aws::Client 自体で再試行を行い、0 は再試行しないことを意味します。バックアップ/復元時にのみ適用されます。

​

backup_restore_s3_retry_initial_backoff_ms

バックアップおよび復元中に最初の再試行を行う前の初期バックオフ遅延 (ミリ秒) です。以降の再試行では、backup_restore_s3_retry_max_backoff_ms で指定された最大値に達するまで、遅延が指数関数的に増加します。

​

backup_restore_s3_retry_jitter_factor

バックアップおよびリストア操作中の Aws::Client::RetryStrategy において、再試行時の backoff 遅延に適用されるジッタ係数です。算出された backoff 遅延には、最大 backup_restore_s3_retry_max_backoff_ms まで、[1.0, 1.0 + jitter] の範囲のランダムな係数が乗算されます。[0.0, 1.0] の範囲内である必要があります

​

backup_restore_s3_retry_max_backoff_ms

バックアップおよびリストア操作中の再試行の間隔の最大遅延時間 (ミリ秒) 。

​

backup_slow_all_threads_after_retryable_s3_error

true に設定すると、同じバックアップエンドポイントへの S3 リクエストを実行しているすべてのスレッドは、いずれか 1 つの S3 リクエストが ‘Slow Down’ などの再試行可能な S3 エラーに遭遇した後、速度が抑えられます。 false に設定すると、各スレッドは他のスレッドとは独立して S3 リクエストのバックオフを処理します。

​

cache_warmer_threads

ClickHouse Cloud でのみ有効です。cache_populated_by_fetch が有効な場合に、新しいデータパーツをファイルシステムキャッシュへ先回りしてダウンロードするためのバックグラウンドスレッド数。無効にするには 0 を指定します。

​

calculate_text_stack_trace

クエリ実行中に例外が発生した場合、テキスト形式のスタックトレースを計算します。これはデフォルトの設定です。これにはシンボルのルックアップが必要なため、大量の不正なクエリを実行するファジングテストでは処理が遅くなることがあります。通常、このオプションを無効にすべきではありません。

​

cancel_http_readonly_queries_on_client_close

クライアントが応答を待たずに接続を閉じた場合、HTTP の読み取り専用クエリ (例: SELECT) をキャンセルします。

Cloud でのデフォルト値: 1。

​

cast_ipv4_ipv6_default_on_conversion_error

IPv4 への CAST 演算子、IPv6 型への CAST 演算子、toIPv4 関数、および toIPv6 関数は、変換エラー時に例外をスローする代わりにデフォルト値を返します。

​

cast_keep_nullable

CAST 操作で Nullable データ型を保持するかどうかを制御します。

この設定を有効にすると、CAST 関数の引数が Nullable である場合、結果も Nullable 型に変換されます。この設定を無効にすると、結果は常に宛先の型そのものになります。

設定可能な値:

• 0 — CAST の結果は、指定した宛先の型そのものになります。
• 1 — 引数の型が Nullable の場合、CAST の結果は Nullable(DestinationDataType) に変換されます。

例

次のクエリでは、結果は宛先のデータ型そのものになります:

SET cast_keep_nullable = 0;
SELECT CAST(toNullable(toInt32(0)) AS Int32) as x, toTypeName(x);

結果:

┌─x─┬─toTypeName(CAST(toNullable(toInt32(0)), 'Int32'))─┐
│ 0 │ Int32                                             │
└───┴───────────────────────────────────────────────────┘

次のクエリを実行すると、宛先のデータ型に Nullable 修飾子が適用されます。

SET cast_keep_nullable = 1;
SELECT CAST(toNullable(toInt32(0)) AS Int32) as x, toTypeName(x);

結果:

┌─x─┬─toTypeName(CAST(toNullable(toInt32(0)), 'Int32'))─┐
│ 0 │ Nullable(Int32)                                   │
└───┴───────────────────────────────────────────────────┘

関連項目

• CAST 関数

​

cast_string_to_date_time_mode

String から cast するときに、日付と時刻のテキスト表現に使用するパーサーを選択できます。

設定可能な値:

• 'best_effort' — 拡張パースを有効にします。

  ClickHouse は、基本的な YYYY-MM-DD HH:MM:SS フォーマットに加え、ISO 8601 のすべての日付・時刻フォーマットをパースできます。たとえば、'2018-06-08T01:02:03.000Z' です。

• 'best_effort_us' — best_effort とほぼ同じです (違いについては parseDateTimeBestEffortUS を参照してください)

• 'basic' — 基本パーサーを使用します。

  ClickHouse は、基本的な YYYY-MM-DD HH:MM:SS または YYYY-MM-DD フォーマットのみをパースできます。たとえば、2019-08-20 10:18:56 または 2019-08-20 です。

関連項目:

• DateTime データ型
• 日付と時刻を扱う関数

​

cast_string_to_dynamic_use_inference

String から Dynamic への変換時に型推論を使用する

​

cast_string_to_variant_use_inference

String から Variant への変換時に型推論を使用します。

​

check_named_collection_dependencies

DROP NAMED COLLECTION を実行しても、それに依存するテーブルに影響が出ないことを確認します

​

check_query_single_value_result

MergeTree ファミリーのエンジンにおける CHECK TABLE クエリ結果の詳細度を定義します。

設定可能な値:

• 0 — クエリは、テーブルの個々のデータパートごとのチェック状態を表示します。
• 1 — クエリは、テーブル全体のチェック状態を表示します。

​

check_referential_table_dependencies

DDLクエリ (DROP TABLE や RENAME など) によって参照関係が壊れないことを確認します

​

check_table_dependencies

DDL クエリ (DROP TABLE や RENAME など) で依存関係が壊れないことを確認します

​

checksum_on_read

読み取り時にチェックサムを検証します。これはデフォルトで有効になっており、本番環境では常に有効にしておくべきです。この設定を無効にしても、メリットは期待できません。利用するのは実験やベンチマークの場合に限るべきです。この設定が適用されるのは、MergeTree family のテーブルのみです。その他のテーブルエンジンや、ネットワーク経由でデータを受信する場合は、チェックサムは常に検証されます。

​

cloud_mode

Cloudモード

Cloud でのデフォルト値: 1.

​

cloud_mode_database_engine

Cloud で許可されるデータベースエンジン。1 - DDL を Replicated データベースを使用するように書き換える、2 - DDL を Shared データベースを使用するように書き換える

Cloud でのデフォルト値: 2.

​

cloud_mode_engine

Cloud で許可されるエンジンファミリー。

• 0 - すべて許可
• 1 - DDLs を *ReplicatedMergeTree を使用するように書き換える
• 2 - DDLs を SharedMergeTree を使用するように書き換える
• 3 - リモートディスクが明示的に指定されている場合を除き、DDLs を SharedMergeTree を使用するように書き換える
• 4 - 3 と同じですが、さらに Distributed の代わりに Alias を使用します (Alias テーブルは Distributed テーブルの宛先テーブルを指すため、対応するローカルテーブルが使用されます)

公開部分を最小限にするための UInt64

Cloud でのデフォルト値: 2.

​

cluster_for_parallel_replicas

現在のサーバーが属する分片のクラスター

Cloud でのデフォルト値: default。

​

cluster_function_process_archive_on_multiple_nodes

true に設定すると、クラスター関数でのアーカイブ処理のパフォーマンスが向上します。互換性を確保し、以前のバージョンでアーカイブを含むクラスター関数を使用している場合に 25.7 以降へのアップグレード中のエラーを回避するため、false に設定してください。

​

cluster_table_function_buckets_batch_size

bucket 分割粒度を使用するクラスターテーブル関数で、タスクを分散処理する際に使われる Batch のおおよそのサイズ (バイト単位) を定義します。システムは、少なくともこのサイズに達するまでデータを蓄積します。実際のサイズは、データ境界に合わせるため、これよりわずかに大きくなる場合があります。

​

cluster_table_function_split_granularity

CLUSTER TABLE FUNCTION の実行時に、データをどのようにタスクに分割するかを制御します。

この設定は、クラスター全体での処理の分散粒度を定義します。

• file — 各タスクがファイル全体を処理します。
• bucket — ファイル内の内部データブロックごとにタスクが作成されます (たとえば、Parquet の行グループ) 。

少数の大きなファイルを扱う場合、bucket のようなより細かい粒度を選ぶことで、並列度を向上できることがあります。 たとえば、Parquet ファイルに複数の行グループが含まれている場合、bucket 粒度を有効にすると、各グループを異なるワーカーが独立して処理できます。

​

collect_hash_table_stats_during_aggregation

メモリ割り当てを最適化するため、ハッシュテーブルの統計情報の収集を有効にします

​

collect_hash_table_stats_during_joins

ハッシュテーブルの統計情報の収集を有効にし、メモリ割り当てを最適化します

​

compatibility

compatibility 設定を使用すると、ClickHouse は指定された以前の ClickHouse バージョンのデフォルト設定を使用します。

設定がデフォルト以外の値に変更されている場合、それらの設定はそのまま維持されます (compatibility 設定の影響を受けるのは、変更されていない設定のみです) 。

この設定には、22.3、22.8 のような ClickHouse のバージョン番号を文字列として指定します。値が空の場合、この設定は無効になります。

デフォルトでは無効です。

ClickHouse Cloud では、サービスレベルのデフォルトの compatibility 設定は ClickHouse Cloud Support が設定する必要があります。設定を希望する場合は、サポートケースを作成してください。 ただし、compatibility 設定は、セッションでの SET compatibility = '22.3' やクエリでの SETTINGS compatibility = '22.3' など、標準的な ClickHouse の設定メカニズムを使用して、ユーザー、ロール、プロファイル、クエリ、またはセッションレベルで上書きできます。

​

compatibility_ignore_auto_increment_in_create_table

true の場合はカラム宣言内の AUTO_INCREMENT キーワードを無視し、false の場合はエラーを返します。これにより MySQL からの移行が容易になります

​

compatibility_ignore_collation_in_create_table

CREATE TABLE で collation を無視する互換性設定

​

compatibility_s3_presigned_url_query_in_path

互換性設定です。有効にすると、事前署名付きURLのクエリパラメータ (例: X-Amz-*) が S3キーに含まれるため (従来の動作) 、パス内で ’?’ がワイルドカードとして扱われます。 無効時 (デフォルト) には、事前署名付きURLのクエリパラメータは URL クエリ内に保持されるため、’?’ がワイルドカードとして解釈されるのを防げます。

​

compile_aggregate_expressions

集約関数のネイティブコードへの JIT コンパイルを有効または無効にします。この設定を有効にすると、パフォーマンスが向上する可能性があります。

設定可能な値:

• 0 — JIT コンパイルを使用せずに集約処理が実行されます。
• 1 — JIT コンパイルを使用して集約処理が実行されます。

関連項目

• min_count_to_compile_aggregate_expression

​

compile_expressions

一部のスカラー関数と演算子をネイティブコードにコンパイルします。

​

compile_sort_description

ソート記述をネイティブコードとしてコンパイルします。

​

connect_timeout

レプリカが存在しない場合の接続タイムアウト。

​

connect_timeout_with_failover_ms

クラスター定義で ‘shard’ および ‘replica’ セクションを使用している場合に、Distributed テーブルエンジンでリモートサーバーへ接続する際のタイムアウト時間 (ミリ秒) です。 接続に失敗した場合は、複数のレプリカへの接続が何度か試行されます。

​

connect_timeout_with_failover_secure_ms

最初の正常なレプリカを選択するための接続タイムアウト (セキュア接続用) 。

​

connection_pool_max_wait_ms

接続プールがいっぱいの場合に、接続を待機する時間をミリ秒単位で指定します。

設定可能な値:

• 正の整数。
• 0 — タイムアウトなし。

​

connections_with_failover_max_tries

Distributed テーブルエンジンで、各レプリカに対して接続を試行する最大回数です。

​

convert_query_to_cnf

true に設定すると、SELECT クエリは連言標準形 (CNF) に変換されます。クエリを CNF に書き換えることで、実行が高速になる場合があります (詳しくは、このGitHub issueを参照してください) 。

たとえば、次の SELECT クエリは変更されません (これがデフォルトの動作です) 。

EXPLAIN SYNTAX
SELECT *
FROM
(
    SELECT number AS x
    FROM numbers(20)
) AS a
WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15))
SETTINGS convert_query_to_cnf = false;

結果は次のとおりです。

┌─explain────────────────────────────────────────────────────────┐
│ SELECT x                                                       │
│ FROM                                                           │
│ (                                                              │
│     SELECT number AS x                                         │
│     FROM numbers(20)                                           │
│     WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15)) │
│ ) AS a                                                         │
│ WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15))     │
│ SETTINGS convert_query_to_cnf = 0                              │
└────────────────────────────────────────────────────────────────┘

convert_query_to_cnf を true に設定して、どう変わるか見てみましょう。

EXPLAIN SYNTAX
SELECT *
FROM
(
    SELECT number AS x
    FROM numbers(20)
) AS a
WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15))
SETTINGS convert_query_to_cnf = true;

WHERE句がCNFに書き換えられている点に注目してください。ただし、結果セットはまったく同じで、ブール論理は変わっていません。

┌─explain───────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ SELECT x                                                                                                              │
│ FROM                                                                                                                  │
│ (                                                                                                                     │
│     SELECT number AS x                                                                                                │
│     FROM numbers(20)                                                                                                  │
│     WHERE ((x <= 15) OR (x <= 5)) AND ((x <= 15) OR (x >= 1)) AND ((x >= 10) OR (x <= 5)) AND ((x >= 10) OR (x >= 1)) │
│ ) AS a                                                                                                                │
│ WHERE ((x >= 10) OR (x >= 1)) AND ((x >= 10) OR (x <= 5)) AND ((x <= 15) OR (x >= 1)) AND ((x <= 15) OR (x <= 5))     │
│ SETTINGS convert_query_to_cnf = 1                                                                                     │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

設定可能な値: true, false

​

correlated_subqueries_default_join_kind

デコリレーション後のクエリプランにおける JOIN の種類を制御します。デフォルト値は right で、この場合、デコリレーション後のプランにはサブクエリ入力が右側にある RIGHT JOIN が含まれます。

設定可能な値:

• left - デコリレーション処理により LEFT JOIN が生成され、入力テーブルは左側に配置されます。
• right - デコリレーション処理により RIGHT JOIN が生成され、入力テーブルは右側に配置されます。

​

correlated_subqueries_substitute_equivalent_expressions

フィルタ式を使用して等価な式を推論し、CROSS JOIN を作成する代わりにそれらの式に置き換えます。

​

correlated_subqueries_use_in_memory_buffer

相関サブクエリの入力にインメモリバッファを使用し、繰り返し評価されるのを防ぎます。

​

count_distinct_implementation

COUNT(DISTINCT …) 構文の実行に使用する uniq* 関数を指定します。

設定可能な値:

• uniq
• uniqCombined
• uniqCombined64
• uniqHLL12
• uniqExact

​

count_distinct_optimization

count distinct を group by のサブクエリに書き換える

​

count_matches_stop_at_empty_match

countMatches 関数で、パターンが長さ0に一致した時点でカウントを停止します。

​

create_if_not_exists

デフォルトで CREATE ステートメントの IF NOT EXISTS を有効にします。この設定または IF NOT EXISTS のいずれかが指定されていて、指定した名前のテーブルがすでに存在する場合、例外は発生しません。

​

create_index_ignore_unique

CREATE UNIQUE INDEX の UNIQUE キーワードを無視します。SQL 互換性テスト向けの設定です。

​

create_replicated_merge_tree_fault_injection_probability

ZooKeeper にメタデータを作成した後、table の作成時に障害を挿入する確率

​

create_table_empty_primary_key_by_default

ORDER BY と PRIMARY KEY が指定されていない場合に、空の主キーを持つ *MergeTree テーブルを作成できるようにします

​

cross_join_min_bytes_to_compress

CROSS JOIN で圧縮するブロックの最小サイズです。値が 0 の場合、このしきい値は無効になります。ブロックは、2 つのしきい値 (行数またはバイト数) のいずれかに達すると圧縮されます。

​

cross_join_min_rows_to_compress

CROSS JOIN でブロックを圧縮するための最小行数。値が 0 の場合、このしきい値は無効になります。2 つのしきい値 (行数またはバイト数) のいずれかに達すると、このブロックは圧縮されます。

​

cross_to_inner_join_rewrite

WHERE 句に結合条件式がある場合、comma/cross join の代わりに inner join を使用します。値: 0 - 書き換えなし、1 - comma/cross の場合に、可能であれば適用、2 - すべての comma join を強制的に書き換え、cross は可能であれば書き換える

​

data_type_default_nullable

カラム定義で明示的な修飾子 NULL or NOT NULL を指定しない場合、データ型を Nullable として扱うことを許可します。

設定可能な値:

• 1 — カラム定義のデータ型は、デフォルトで Nullable に設定されます。
• 0 — カラム定義のデータ型は、デフォルトで Nullable には設定されません。

​

database_atomic_wait_for_drop_and_detach_synchronously

すべてのDROPおよびDETACHクエリにSYNC修飾子を追加します。

設定可能な値:

• 0 — クエリは遅延して実行されます。
• 1 — クエリは遅延せずに実行されます。

​

database_datalake_require_metadata_access

データベースエンジン DataLakeCatalog でテーブルのメタデータを取得する権限がない場合に、エラーをスローするかどうかを指定します。

​

database_replicated_allow_explicit_uuid

0 - Replicated databases 内のテーブルで UUID を明示的に指定することはできません。1 - 許可します。2 - 許可しますが、指定された UUID は無視され、代わりにランダムな UUID が生成されます。

​

database_replicated_allow_heavy_create

Replicated データベースエンジンで長時間実行される DDL クエリ (CREATE AS SELECT および POPULATE) を許可します。DDL キューが長時間ブロックされる可能性がある点に注意してください。

​

database_replicated_allow_only_replicated_engine

エンジンが Replicated のデータベースでは、Replicated テーブルのみ作成できます

Cloud でのデフォルト値: 1.

​

database_replicated_allow_replicated_engine_arguments

0 - Replicated database 内の *MergeTree テーブルで、ZooKeeper path とレプリカ名を明示的に指定することを許可しません。1 - 許可します。2 - 許可しますが、指定された path は無視し、代わりにデフォルトのものを使用します。3 - 許可し、警告もログに記録しません。

​

database_replicated_always_detach_permanently

データベースエンジンがReplicatedの場合、DETACH TABLE は DETACH TABLE PERMANENTLY として実行されます

​

database_replicated_enforce_synchronous_settings

一部のクエリで同期的な待機を強制します (関連項目: database_atomic_wait_for_drop_and_detach_synchronously、mutations_sync、alter_sync) 。これらの設定を有効にすることは推奨されません。

​

database_replicated_initial_query_timeout_sec

初回の DDLクエリが、Replicatedデータベースによる以前の DDLキューのエントリの処理が完了するまで待機する時間を、秒単位で設定します。

設定可能な値:

• 正の整数。
• 0 — 無制限。

​

database_shared_drop_table_delay_seconds

削除されたテーブルが Shared データベースから実際に削除されるまでの猶予時間 (秒) です。この時間内であれば、UNDROP TABLE ステートメントを使用してテーブルを復元できます。

​

decimal_check_overflow

Decimal の算術演算および比較演算のオーバーフローをチェックします

​

deduplicate_blocks_in_dependent_materialized_views

Replicated* tables からデータを受け取る materialized view に対する重複排除チェックを有効または無効にします。

設定可能な値:

0 — 無効。 1 — 有効。

有効にすると、ClickHouse は Replicated* tables に依存する materialized view 内のブロックに対して重複排除を実行します。 この設定は、障害により挿入処理が再試行された場合に、materialized view に重複データが含まれないようにするのに役立ちます。

関連項目

• IN 演算子での NULL 処理

​

deduplicate_insert

INSERT INTO のブロック重複排除を有効または無効にします (Replicated* テーブルの場合) 。 この設定は、insert_deduplicate および async_insert_deduplicate の設定をオーバーライドします。 この設定には、次の 3 つの設定可能な値があります。

• disable — INSERT INTO クエリの重複排除は無効です。
• enable — INSERT INTO クエリの重複排除は有効です。
• backward_compatible_choice — 特定の insert タイプで insert_deduplicate または async_insert_deduplicate が有効になっている場合、重複排除が有効になります。

​

deduplicate_insert_select

INSERT SELECT のブロック重複排除 (Replicated* テーブル向け) を有効または無効にします。 この設定は、INSERT SELECT クエリに対して insert_deduplicate と deduplicate_insert より優先されます。 この設定には 4 つの設定可能な値があります:

• disable — INSERT SELECT クエリの重複排除は無効です。
• force_enable — INSERT SELECT クエリの重複排除は有効です。SELECT の結果が安定していない場合、例外がスローされます。
• enable_when_possible — insert_deduplicate が有効で、かつ SELECT の結果が安定している場合に重複排除が有効になり、それ以外の場合は無効になります。
• enable_even_for_bad_queries - insert_deduplicate が有効な場合に重複排除が有効になります。SELECT の結果が安定していない場合は警告がログに記録されますが、重複排除を有効にしたままクエリは実行されます。このオプションは後方互換性のためのものです。予期しない結果につながる可能性があるため、代わりに他のオプションを使用することを検討してください。

​

default_materialized_view_sql_security

materialized view の作成時に、SQL SECURITY オプションのデフォルト値を設定できます。SQL security の詳細。

デフォルト値は DEFINER です。

​

default_max_bytes_in_join

制限が必要で、max_bytes_in_join が設定されていない場合の、右側のテーブルの最大サイズ。

​

default_normal_view_sql_security

通常ビューの作成時に、デフォルトの SQL SECURITY オプションを設定できます。SQL security について詳しくは、こちら。

デフォルト値は INVOKER です。

​

default_table_engine

CREATE ステートメントで ENGINE が設定されていない場合に使用されるデフォルトのテーブルエンジンです。

設定可能な値:

• 有効な任意のテーブルエンジン名を表す文字列

Cloud でのデフォルト値: SharedMergeTree。

例

クエリ:

SET default_table_engine = 'Log';

SELECT name, value, changed FROM system.settings WHERE name = 'default_table_engine';

結果:

┌─name─────────────────┬─value─┬─changed─┐
│ default_table_engine │ Log   │       1 │
└──────────────────────┴───────┴─────────┘

この例では、Engine を指定しない新しいテーブルはすべて、Log テーブルエンジンが使用されます。

クエリ:

CREATE TABLE my_table (
    x UInt32,
    y UInt32
);

SHOW CREATE TABLE my_table;

結果:

┌─statement────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.my_table
(
    `x` UInt32,
    `y` UInt32
)
ENGINE = Log
└──────────────────────────────────────────────────────────────────────────┘

​

default_temporary_table_engine

default_table_engine と同様ですが、一時テーブルに対して適用されます。

この例では、Engine を指定していない新しい一時テーブルでは、Log テーブルエンジンが使用されます。

クエリ:

SET default_temporary_table_engine = 'Log';

CREATE TEMPORARY TABLE my_table (
    x UInt32,
    y UInt32
);

SHOW CREATE TEMPORARY TABLE my_table;

結果:

┌─statement────────────────────────────────────────────────────────────────┐
│ CREATE TEMPORARY TABLE default.my_table
(
    `x` UInt32,
    `y` UInt32
)
ENGINE = Log
└──────────────────────────────────────────────────────────────────────────┘

​

default_view_definer

ビューの作成時にデフォルトの DEFINER オプションを設定できます。SQL security の詳細。

デフォルト値は CURRENT_USER です。

​

defer_partition_pruning_after_final

有効な場合 (デフォルト) 、パーティションキーのカラムがソートキーに含まれていない テーブルに対する FINAL クエリでは、パーティションプルーニングはスキップされます。これは 26.3 で導入された、正しさを優先する動作です。FINAL では、同じ主キーを共有しながら 異なるパーティションに存在する行を重複排除する必要が生じることがあり、パーティションプルーニングを行うと、 そうした行が重複排除の入力から暗黙的に除外されてしまいます。

無効な場合は、FINAL を使用していてもパーティションプルーニングが適用され、 26.3 より前の動作に戻ります。これは、パーティションカラムに対する WHERE predicate を含む クエリでは大幅に高速になる可能性がありますが、同じ主キーを持つ行が異なるパーティションに存在し得ない場合にのみ 正しく動作します。たとえば、パーティションカラムが insert 時に設定され、 その後は決して変更されないイベントログテーブルなどが該当します。

この設定の影響を受けるのは、パーティションキーのカラムがソートキーに含まれていない パーティション化テーブルのみです。それ以外のテーブルでは、パーティションプルーニングは常に適用されます。

設定可能な値:

• 0 — FINAL の前にパーティションプルーニングを適用します (26.3 より前の動作。高速ですが、一般的には安全ではありません) 。
• 1 — FINAL の後までパーティションプルーニングを遅らせます (デフォルト。正しさを優先) 。

​

delta_lake_enable_engine_predicate

delta-kernel の内部的なデータプルーニングを有効にします。

​

delta_lake_enable_expression_visitor_logging

Delta Lake expression visitor のテストレベルのログを有効にします。これらのログは、テストログとしても冗長になりすぎることがあります。

​

delta_lake_insert_max_bytes_in_data_file

Delta Lake の 1 つの挿入データファイルに対して設定するバイト数の上限を定義します。

​

delta_lake_insert_max_rows_in_data_file

Delta Lake で 1 つの挿入データファイルに含められる行数の上限を定義します。

​

delta_lake_log_metadata

Delta Lake のメタデータファイルをシステムテーブルに記録する機能を有効にします。

​

delta_lake_reload_schema_for_consistency

有効にすると、クエリ解析時に使用されるスキーマと実行時に使用されるスキーマの 一貫性を確保するため、各クエリの実行前に Delta Lake のメタデータからスキーマが再読み込みされます。

​

delta_lake_snapshot_end_version

読み取り対象の Delta Lake スナップショットの終了バージョン。値 -1 は最新バージョンを読み取ることを意味します (値 0 は有効なスナップショットバージョンです) 。

​

delta_lake_snapshot_start_version

読み取る Delta Lake スナップショットの開始バージョンを指定します。値 -1 は最新バージョンを読み取ることを意味します (値 0 も有効なスナップショットバージョンです) 。

​

delta_lake_snapshot_version

読み取る Delta Lake スナップショットのバージョンを指定します。値が -1 の場合は最新バージョンを読み取ります (値 0 も有効なスナップショットバージョンです) 。

​

delta_lake_throw_on_engine_predicate_error

delta-kernel でスキャン述語を解析する際にエラーが発生した場合に、例外をスローするようにします。

​

describe_compact_output

true の場合、DESCRIBE クエリの結果にはカラム名と型のみが含まれます

​

describe_include_subcolumns

DESCRIBE クエリでサブカラムの表示を有効にします。たとえば、Tuple のメンバーや、Map、Nullable、Array データ型のサブカラムが対象です。

設定可能な値:

• 0 — DESCRIBE クエリにサブカラムは含まれません。
• 1 — DESCRIBE クエリにサブカラムが含まれます。

例

DESCRIBE ステートメントの例を参照してください。

​

describe_include_virtual_columns

true の場合、テーブルの仮想カラムが DESCRIBE クエリの結果に含まれます

​

dialect

クエリの解析に使用するダイアレクト

​

dictionary_use_async_executor

Dictionary ソースの読み取り用パイプラインを複数のスレッドで実行します。ローカル CLICKHOUSE ソースを持つ Dictionary でのみサポートされています。

​

dictionary_validate_primary_key_type

Dictionaryの主キー型を検証します。デフォルトでは、シンプルレイアウトの id 型は暗黙的に UInt64 に変換されます。

​

distinct_overflow_mode

データ量がいずれかの制限を超えた場合の動作を設定します。

設定可能な値:

• throw: 例外をスローします (デフォルト) 。
• break: クエリの実行を停止し、ソースデータが尽きた場合と同様に、 部分的な結果を返します。

​

distributed_aggregation_memory_efficient

分散集約の省メモリモードを有効にするかどうか。

​

distributed_background_insert_batch

別名: distributed_directory_monitor_batch_inserts

挿入データをバッチ単位で送信する機能を有効または無効にします。

バッチ送信が有効な場合、Distributed テーブルエンジンは、挿入された複数のデータファイルを個別に送信する代わりに、1 回の操作でまとめて送信しようとします。バッチ送信により、サーバーとネットワークのリソースをより効率的に活用できるため、クラスターのパフォーマンスが向上します。

設定可能な値:

• 1 — 有効。
• 0 — 無効。

​

distributed_background_insert_max_sleep_time_ms

別名: distributed_directory_monitor_max_sleep_time_ms

Distributed テーブルエンジンがデータを送信する際の最大間隔です。distributed_background_insert_sleep_time_ms 設定で指定した間隔が指数関数的に増加するのを制限します。

設定可能な値:

• 正の整数のミリ秒数。

​

distributed_background_insert_sleep_time_ms

別名: distributed_directory_monitor_sleep_time_ms

Distributedテーブルエンジンがデータを送信する際の基本間隔です。実際の間隔は、エラーが発生すると指数関数的に増加します。

設定可能な値:

• 正の整数のミリ秒数。

​

distributed_background_insert_split_batch_on_failure

別名: distributed_directory_monitor_split_batch_on_failure

失敗時にバッチを分割するかどうかを有効/無効にします。

特定のバッチをリモートの分片に送信する際、後段に複雑なパイプライン (たとえば GROUP BY を伴う MATERIALIZED VIEW) があると、Memory limit exceeded などのエラーによって失敗することがあります。この場合、再試行しても改善せず、table の distributed 送信が滞る可能性がありますが、そのバッチ内のファイルを 1 つずつ送信すれば INSERT が成功する場合があります。

そのため、この設定を 1 にすると、そのようなバッチでは batching が無効になります (つまり、失敗したバッチに対して distributed_background_insert_batch を一時的に無効にします) 。

設定可能な値:

• 1 — 有効。
• 0 — 無効。

この設定は、破損したバッチにも影響します (異常な server (マシン) の停止や、Distributed table engine で fsync_after_insert/fsync_directories を使用していないことが原因で発生する場合があります) 。

パフォーマンスに悪影響を及ぼす可能性があるため、自動バッチ分割に依存すべきではありません。

​

distributed_background_insert_timeout

別名: insert_distributed_timeout

Distributed への INSERT クエリのタイムアウトです。insert_distributed_sync が有効な場合にのみ使用されます。値が 0 の場合はタイムアウトしません。

​

distributed_cache_alignment

ClickHouse Cloud でのみ有効です。テスト用の設定のため、変更しないでください

​

distributed_cache_bypass_connection_pool

ClickHouse Cloud でのみ有効です。分散キャッシュ接続プールのバイパスを許可します

​

distributed_cache_connect_backoff_max_ms

ClickHouse Cloud でのみ有効です。分散キャッシュ接続の作成時の最大バックオフ時間 (ミリ秒) です。

​

distributed_cache_connect_backoff_min_ms

ClickHouse Cloud でのみ有効です。分散キャッシュ接続を作成する際の最小バックオフ時間 (ミリ秒) 。

​

distributed_cache_connect_max_tries

ClickHouse Cloud でのみ有効です。接続に失敗した場合に、分散キャッシュへの接続を再試行する回数

​

distributed_cache_connect_timeout_ms

ClickHouse Cloud でのみ有効です。分散キャッシュサーバーへの接続時のタイムアウト。

​

distributed_cache_credentials_refresh_period_seconds

ClickHouse Cloud でのみ有効です。認証情報を更新する間隔です。

​

distributed_cache_data_packet_ack_window

ClickHouse Cloud でのみ有効です。単一の分散キャッシュ読み取りリクエストで、DataPacket シーケンスに対する ACK を送信するためのウィンドウです。

​

distributed_cache_discard_connection_if_unread_data

ClickHouse Cloud でのみ有効です。未読のデータがある場合は接続を破棄します。

​

distributed_cache_fetch_metrics_only_from_current_az

ClickHouse Cloud でのみ有効です。system.distributed_cache_metrics および system.distributed_cache_events では、現在のアベイラビリティゾーンからのみメトリクスを取得します

​

distributed_cache_file_cache_name

ClickHouse Cloud でのみ有効です。CI テスト専用の設定で、分散キャッシュで使用するファイルシステムキャッシュ名を指定します。

​

distributed_cache_log_mode

ClickHouse Cloud でのみ有効です。system.distributed_cache_log への書き込みモードです。

​

distributed_cache_max_unacked_inflight_packets

ClickHouse Cloudでのみ有効です。単一の分散キャッシュ読み取りリクエストで、未確認応答のまま転送中のパケットの最大数

​

distributed_cache_min_bytes_for_seek

ClickHouse Cloud でのみ有効です。分散キャッシュで seek を行う際の最小バイト数です。

​

distributed_cache_pool_behaviour_on_limit

ClickHouse Cloud でのみ有効です。プールの上限に達したときの分散キャッシュ接続の動作を指定します

​

distributed_cache_prefer_bigger_buffer_size

ClickHouse Cloud でのみ有効です。filesystem_cache_prefer_bigger_buffer_size と同様ですが、分散キャッシュ用です。

​

distributed_cache_read_only_from_current_az

ClickHouse Cloud でのみ有効です。現在のアベイラビリティゾーンからのみ読み取るようにします。無効にすると、すべてのアベイラビリティゾーンにあるすべてのキャッシュサーバーから読み取ります。

​

distributed_cache_read_request_max_tries

ClickHouse Cloud でのみ有効です。分散キャッシュの読み取りリクエストが失敗した場合の再試行回数

​

distributed_cache_receive_response_wait_milliseconds

ClickHouse Cloud でのみ有効です。分散キャッシュからリクエストに対するデータを受信するまでの待機時間 (ミリ秒)

​

distributed_cache_receive_timeout_milliseconds

ClickHouse Cloud でのみ有効です。分散キャッシュからあらゆる種類の応答を受信するまでの待機時間 (ミリ秒) 。

Cloud でのデフォルト値: 20000.

​

distributed_cache_receive_timeout_ms

ClickHouse Cloudでのみ有効です。分散キャッシュサーバーからデータを受信する際のタイムアウトをミリ秒単位で指定します。この期間内に1バイトも受信されなかった場合、例外がスローされます。

​

distributed_cache_send_timeout_ms

ClickHouse Cloud でのみ有効です。distributed cache server へのデータ送信のタイムアウトをミリ秒単位で指定します。クライアントがデータを送信する必要があるにもかかわらず、この時間内に 1 バイトも送信できない場合は、例外がスローされます。

​

distributed_cache_tcp_keep_alive_timeout_ms

ClickHouse Cloud でのみ有効です。TCP が keepalive プローブの送信を開始するまでに、分散キャッシュサーバーへの接続がアイドル状態のままでいる必要がある時間をミリ秒単位で指定します。

​

distributed_cache_throw_on_error

ClickHouse Cloud でのみ有効です。分散キャッシュとの通信中に発生した例外、または分散キャッシュから返された例外を再スローします。それ以外の場合、エラー時は分散キャッシュをスキップする動作にフォールバックします。

​

distributed_cache_use_clients_cache_for_read

ClickHouse Cloud でのみ有効です。読み取りリクエストにはクライアント cache を使用します。

​

distributed_cache_use_clients_cache_for_write

ClickHouse Cloud でのみ有効です。書き込みリクエストにクライアントの cache を使用します。

​

distributed_cache_wait_connection_from_pool_milliseconds

ClickHouse Cloudでのみ有効です。distributed_cache_pool_behaviour_on_limit が wait の場合、接続プールから接続を取得するまでの待機時間 (ミリ秒) 。

​

distributed_cache_write_request_max_tries

ClickHouse Cloud でのみ有効です。分散キャッシュの書き込みリクエストが失敗した場合の再試行回数

​

distributed_connections_pool_size

単一の分散テーブルに対するすべてのクエリの分散処理で使用する、リモートサーバーへの同時接続数の上限です。値は、クラスター内のサーバー数以上に設定することを推奨します。

​

distributed_ddl_entry_format_version

distributed DDL (ON CLUSTER) クエリの互換性バージョンです

Cloud でのデフォルト値: 6.

​

distributed_ddl_output_mode

分散 DDL クエリの結果のフォーマットを設定します。

設定可能な値:

• throw — クエリが完了したすべてのホストについて、クエリの実行ステータスを含む結果セットを返します。一部のホストでクエリが失敗した場合は、最初の例外を再送出します。一部のホストでまだクエリが完了しておらず、distributed_ddl_task_timeout を超過した場合は、TIMEOUT_EXCEEDED 例外を送出します。
• none — throw と似ていますが、分散 DDL クエリは結果セットを返しません。
• null_status_on_timeout — 対応するホストでクエリがまだ完了していない場合、TIMEOUT_EXCEEDED を送出する代わりに、結果セットの一部の行で実行ステータスとして NULL を返します。
• never_throw — 一部のホストでクエリが失敗していても、TIMEOUT_EXCEEDED を送出せず、例外の再送出も行いません。
• none_only_active - none と似ていますが、Replicated データベースの非アクティブなレプリカは待機しません。注: このモードでは、一部のレプリカでクエリが実行されなかったことや、そのクエリがバックグラウンドで実行されることを判別できません。
• null_status_on_timeout_only_active — null_status_on_timeout と似ていますが、Replicated データベースの非アクティブなレプリカは待機しません
• throw_only_active — throw と似ていますが、Replicated データベースの非アクティブなレプリカは待機しません

Cloud でのデフォルト値: none_only_active.

​

distributed_ddl_task_timeout

クラスター内のすべてのホストからの DDLクエリの応答に対するタイムアウトを設定します。DDL リクエストがすべてのホストで実行されていない場合、応答にはタイムアウトエラーが含まれ、リクエストは非同期モードで実行されます。負の値は無制限を意味します。

設定可能な値:

• 正の整数。
• 0 — 非同期モード。
• 負の整数 — タイムアウトなし。

​

distributed_foreground_insert

別名: insert_distributed_sync

Distributed テーブルへのデータの同期挿入を有効または無効にします。

デフォルトでは、Distributed テーブルにデータを挿入すると、ClickHouse サーバーはバックグラウンドモードでクラスターのノードにデータを送信します。distributed_foreground_insert=1 の場合、データは同期的に処理され、すべての分片にすべてのデータが保存されて初めて INSERT 操作は成功します (internal_replication が true の場合は、各分片で少なくとも 1 つのレプリカ) 。

設定可能な値:

• 0 — データはバックグラウンドモードで挿入されます。
• 1 — データは同期モードで挿入されます。

Cloud でのデフォルト値: 1。

関連項目

• Distributed テーブルエンジン
• 分散テーブルの管理

​

distributed_group_by_no_merge

分散クエリ処理で、異なるサーバーからの集約状態をマージしません。異なる分片に異なるキーがあることが確実な場合に使用できます。

設定可能な値:

• 0 — 無効 (最終的なクエリ処理はイニシエーター ノードで行われます) 。
• 1 - 分散クエリ処理で、異なるサーバーからの集約状態をマージしません (クエリは分片上で完全に処理され、イニシエーターはデータをプロキシするだけです) 。異なる分片に異なるキーがあることが確実な場合に使用できます。
• 2 - 1 と同じですが、ORDER BY と LIMIT はイニシエーターで適用します (distributed_group_by_no_merge=1 のように、クエリがリモート ノード上で完全に処理される場合は適用できません) (ORDER BY や LIMIT を含むクエリで使用できます) 。

例

SELECT *
FROM remote('127.0.0.{2,3}', system.one)
GROUP BY dummy
LIMIT 1
SETTINGS distributed_group_by_no_merge = 1
FORMAT PrettyCompactMonoBlock

┌─dummy─┐
│     0 │
│     0 │
└───────┘

SELECT *
FROM remote('127.0.0.{2,3}', system.one)
GROUP BY dummy
LIMIT 1
SETTINGS distributed_group_by_no_merge = 2
FORMAT PrettyCompactMonoBlock

┌─dummy─┐
│     0 │
└───────┘

​

distributed_index_analysis

索引解析はレプリカ間で分散実行されます。 共有ストレージやクラスター内の大規模データで効果を発揮します。 cluster_for_parallel_replicas のレプリカを使用します。

関連項目

• distributed_index_analysis_for_non_shared_merge_tree
• distributed_index_analysis_min_parts_to_activate
• distributed_index_analysis_min_indexes_bytes_to_activate

​

distributed_index_analysis_for_non_shared_merge_tree

SharedMergeTree 以外の (Cloud 専用の) エンジンでも、分散索引解析を有効にします。

​

distributed_index_analysis_only_on_coordinator

有効にすると、分散索引解析はコーディネーター上でのみ実行されます。 これにより、述語にサブクエリ (例: IN (SELECT ...)) が含まれる場合に、O(N^2) のクエリ生成が発生するのを防げます。 そうしないと、各フォロワーレプリカがそれぞれ独自に分散索引解析をトリガーしてしまうためです。 ただし、サブクエリで大きなテーブルを使用する場合は、分散索引解析の効率が低下します。

​

distributed_insert_skip_read_only_replicas

Distributed への INSERT クエリで、読み取り専用レプリカをスキップするかどうかを指定します。

設定可能な値:

• 0 — INSERT は通常どおり実行され、読み取り専用レプリカに送信されると失敗します
• 1 — イニシエーターは、データを分片に送信する前に読み取り専用レプリカをスキップします。

​

distributed_plan_default_reader_bucket_count

分散クエリで並列読み取りを行う際のデフォルトのタスク数です。タスクはレプリカ間に分散されます。

​

distributed_plan_default_shuffle_join_bucket_count

分散シャッフルハッシュ結合のデフォルトのバケット数。

​

distributed_plan_execute_locally

分散クエリプラン内のすべてのタスクをローカルで実行します。テストやデバッグに役立ちます。

​

distributed_plan_force_exchange_kind

分散クエリの各ステージ間で、指定した種類の Exchange 演算子を使用するよう強制します。

設定可能な値:

• ” - どの種類の Exchange 演算子も強制せず、オプティマイザに選択させます。
• ‘Persisted’ - オブジェクトストレージ上の一時ファイルを使用します。
• ‘Streaming’ - Exchange データをネットワーク経由でストリーミングします。

​

distributed_plan_force_shuffle_aggregation

分散クエリプランで、PartialAggregation + Merge の代わりに Shuffle 集約戦略を使用します。

​

distributed_plan_max_rows_to_broadcast

分散クエリプランで、shuffle join の代わりに broadcast join を使用する場合の最大行数。

​

distributed_plan_optimize_exchanges

分散クエリプラン内の不要な exchange を削除します。デバッグ時は無効にしてください。

​

distributed_plan_prefer_replicas_over_workers

レプリカで実行するため、分散クエリプランをシリアライズします。

​

distributed_product_mode

分散サブクエリの動作を変更します。

ClickHouse は、クエリに分散テーブルの積が含まれる場合、つまり分散テーブルへのクエリに、その分散テーブルに対する non-GLOBAL サブクエリが含まれる場合に、この設定を適用します。

制限事項:

• IN および JOIN のサブクエリにのみ適用されます。
• FROM 句で、複数の分片を含む分散テーブルが使用されている場合にのみ適用されます。
• サブクエリの対象が、複数の分片を含む分散テーブルである場合にのみ適用されます。
• テーブル値remote関数には適用されません。

設定可能な値:

• deny — デフォルト値。これらの種類のサブクエリの使用を禁止します (“Double-distributed in/JOIN subqueries is denied” 例外を返します) 。
• local — サブクエリ内の database と table を、通常の IN/JOIN はそのままに、宛先 server (分片) 上のローカルなものに置き換えます。
• global — IN/JOIN クエリを GLOBAL IN/GLOBAL JOIN に置き換えます。
• allow — これらの種類のサブクエリの使用を許可します。

​

distributed_push_down_limit

各分片に LIMIT を個別に適用するかどうかを切り替えます。

これにより、以下を回避できます。

• 余分な行をネットワーク越しに送信すること。
• イニシエーターで LIMIT を超える行を処理すること。

バージョン 21.9 以降では、結果が不正確になることはなくなりました。これは、distributed_push_down_limit がクエリ実行を変更するのは、少なくとも次の条件のいずれかを満たす場合に限られるためです。

• distributed_group_by_no_merge > 0。
• クエリに GROUP BY/DISTINCT/LIMIT BY がなく、ORDER BY/LIMIT がある 場合。
• クエリに GROUP BY/DISTINCT/LIMIT BY と ORDER BY/LIMIT があり、かつ次の条件を満たす場合:
  • optimize_skip_unused_shards が有効。
  • optimize_distributed_group_by_sharding_key が有効。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

関連項目:

• distributed_group_by_no_merge
• optimize_skip_unused_shards
• optimize_distributed_group_by_sharding_key

​

distributed_replica_error_cap

• 型: unsigned int
• デフォルト値: 1000

各レプリカのエラー数はこの値が上限となり、1 つのレプリカに過剰な数のエラーが蓄積されるのを防ぎます。

関連項目:

• load_balancing
• テーブルエンジン Distributed
• distributed_replica_error_half_life
• distributed_replica_max_ignored_errors

​

distributed_replica_error_half_life

• Type: Seconds
• デフォルト値: 60 Seconds

分散テーブルで発生したエラーがどれくらいの速さで 0 に戻るかを制御します。たとえば、あるレプリカがしばらく利用不能で、その間に 5 件のエラーが蓄積し、distributed_replica_error_half_life が 1 秒に設定されている場合、そのレプリカは最後のエラーから 3 秒後に正常と見なされます。

関連項目:

• load_balancing
• Table engine Distributed
• distributed_replica_error_cap
• distributed_replica_max_ignored_errors

​

distributed_replica_max_ignored_errors

• 型: unsigned int
• デフォルト値: 0

レプリカの選択時に (load_balancing アルゴリズムに従って) 無視されるエラーの数です。

関連項目:

• load_balancing
• Table engine Distributed
• distributed_replica_error_cap
• distributed_replica_error_half_life

​

do_not_merge_across_partitions_select_final

異なるパーティションをまたぐマージを回避することで、FINAL クエリを改善します。

有効にすると、SELECT FINAL クエリの実行時に、異なるパーティションのパーツがまとめてマージされなくなります。代わりに、マージは各パーティション内でのみ個別に行われます。これにより、パーティション化されたテーブルを扱う際のクエリパフォーマンスが大幅に向上する可能性があります。

​

dynamic_disk_allow_from_env

動的ディスク設定 (つまり disk() 関数の引数) で from_env 置換を使用できるようにします。 テーブルストレージの定義時にユーザーが任意の環境変数を読み取れないよう、デフォルトでは無効になっています。

​

dynamic_disk_allow_from_zk

動的ディスク設定 (つまり disk() 関数の引数) で from_zk 置換を使用できるようにします。 デフォルトでは無効です。

​

dynamic_disk_allow_include

動的ディスク設定 (つまり disk() 関数の引数) で include を使用できるようにします。 デフォルトでは無効です。

​

dynamic_throw_on_type_mismatch

デフォルト実装を使用して Dynamic カラムに関数を適用する際に、 実際の型がその関数と互換性のない行でどう動作するかを制御します。

• true (デフォルト) — 例外をスローします。
• false — 代わりに、それらの行では NULL を返します。

​

empty_result_for_aggregation_by_constant_keys_on_empty_set

空の入力セットを定数キーで集約する場合、空の結果を返します。

​

empty_result_for_aggregation_by_empty_set

空のセットをキーなしで集約する際に、空の結果を返します。

​

enable_adaptive_memory_spill_scheduler

プロセッサによるデータの外部ストレージへの適応的なスピルをトリガーします。現在サポートされているのは grace join のみです。

​

enable_add_distinct_to_in_subqueries

IN サブクエリで DISTINCT を有効にします。これはトレードオフのある設定です。有効にすると、一意の値のみが送信されるため、分散 IN サブクエリで転送される一時テーブルのサイズを大幅に削減でき、分片間のデータ転送を大きく高速化できます。 ただし、この設定を有効にすると、重複排除 (DISTINCT) を実行する必要があるため、各ノードで追加のマージ処理負荷が発生します。ネットワーク転送がボトルネックで、追加のマージコストを許容できる場合にこの設定を使用してください。

​

enable_automatic_decision_for_merging_across_partitions_for_final

この設定を有効にすると、パーティションキー式が決定論的であり、かつその式で使用されるすべてのカラムが主キーに含まれている場合、ClickHouse はこの最適化を自動的に有効化します。 この自動導出により、同じ主キー値を持つ行は常に同じパーティションに属することが保証されるため、パーティションをまたぐマージを回避しても安全です。

​

enable_blob_storage_log

ブロブストレージ操作に関する情報を system.blob_storage_log テーブルに書き込む

​

enable_blob_storage_log_for_read_operations

ブロブストレージの読み取り操作に関する情報を system.blob_storage_log テーブルに書き込みます。 これを有効にするには、enable_blob_storage_log も有効になっている必要があります。

​

enable_early_constant_folding

関数やサブクエリの結果を解析し、定数が含まれている場合にクエリを書き換えるクエリ最適化を有効にします

​

enable_extended_results_for_datetime_functions

型 Date32 の結果を拡張範囲で (型 Date と比較して) 返すか、または 型 DateTime64 の結果を拡張範囲で (型 DateTime と比較して) 返すかどうかを有効または無効にします。

設定可能な値:

• 0 — 関数は、すべての型の引数に対して Date または DateTime を返します。
• 1 — 関数は、引数が Date32 または DateTime64 の場合は Date32 または DateTime64 を返し、それ以外の場合は Date または DateTime を返します。

以下の表は、各種の日付時刻関数におけるこの設定の動作を示しています。

関数	enable_extended_results_for_datetime_functions = 0	enable_extended_results_for_datetime_functions = 1
toStartOfYear	Date または DateTime を返す	入力が Date/DateTime の場合は Date/DateTime を返します 入力が Date32/DateTime64 の場合は Date32/DateTime64 を返します
toStartOfISOYear	Date または DateTime を返す	Date/DateTime型の入力にはDate/DateTimeを返します Date32/DateTime64型の入力にはDate32/DateTime64を返します
toStartOfQuarter	Date または DateTime を返す	Date/DateTime 型の入力に対しては Date/DateTime を返します Date32/DateTime64 型の入力に対しては Date32/DateTime64 を返します
toStartOfMonth	Date または DateTime を返す	Date/DateTime 型の入力に対しては Date/DateTime を返します Date32/DateTime64 型の入力に対しては Date32/DateTime64 を返します
toStartOfWeek	Date または DateTime を返す	Date/DateTime 型の入力に対しては Date/DateTime を返します Date32/DateTime64 型の入力に対しては Date32/DateTime64 を返します
toLastDayOfWeek	Date または DateTime を返す	Date/DateTime の入力に対しては Date/DateTime を返します Date32/DateTime64 の入力に対しては Date32/DateTime64 を返します
toLastDayOfMonth	Date または DateTime を返します	Date/DateTime 型の入力には Date/DateTime を返します Date32/DateTime64 型の入力には Date32/DateTime64 を返します
toMonday	Date または DateTime を返します	Date/DateTime 型の入力には Date/DateTime を返します Date32/DateTime64 型の入力には Date32/DateTime64 を返します
toStartOfDay	DateTime を返します 注: 1970～2149 の範囲外の値では正しい結果が得られません	Date/DateTime 型の入力に対しては DateTime を返します Date32/DateTime64 型の入力に対しては DateTime64 を返します
toStartOfHour	DateTime を返します 注: 1970～2149 の範囲外の値では正しい結果が得られません	Date/DateTime 型の入力に対しては DateTime を返します Date32/DateTime64 型の入力に対しては DateTime64 を返します
toStartOfFifteenMinutes	DateTime を返します 注: 1970～2149 の範囲外の値では正しい結果が得られません	Date/DateTime 型の入力に対しては DateTime を返します Date32/DateTime64 型の入力に対しては DateTime64 を返します
toStartOfTenMinutes	DateTime を返します 注: 1970～2149 の範囲外の値では、正しい結果が得られません	Date/DateTime 入力の場合は DateTime を返します Date32/DateTime64 入力の場合は DateTime64 を返します
toStartOfFiveMinutes	DateTime を返します 注: 1970～2149 の範囲外の値では誤った結果が返されます	Date/DateTime 型の入力に対しては DateTime を返します Date32/DateTime64 型の入力に対しては DateTime64 を返します
toStartOfMinute	DateTime を返します 注: 1970～2149 の範囲外の値では誤った結果になる可能性があります	Date/DateTime 型の入力では DateTime を返します Date32/DateTime64 型の入力では DateTime64 を返します
timeSlot	DateTime を返します 注: 1970～2149 の範囲外の値では誤った結果を返す場合があります	Date/DateTime 型の入力では DateTime を返します Date32/DateTime64 型の入力では DateTime64 を返します

​

enable_filesystem_cache

リモートファイルシステムに対して cache を使用します。この設定でディスクの cache をオン/オフすることはできません (ディスクの config で行う必要があります) が、必要に応じて一部のクエリでは cache をバイパスできます

​

enable_filesystem_cache_log

各クエリのfilesystemのキャッシュログを記録できるようにします

​

enable_filesystem_cache_on_write_operations

write-through cache を有効または無効にします。false に設定すると、書き込み操作では write-through cache が無効になります。true に設定すると、server config の cache disk configuration セクションで cache_on_write_operations が有効になっている場合に限り、write-through cache も有効になります。 詳細については、“Using local cache” を参照してください。

Cloud でのデフォルト値: 1.

​

enable_filesystem_read_prefetches_log

クエリ実行中の情報を system.filesystem prefetch_log に記録します。テストまたはデバッグの場合にのみ使用すべきで、デフォルトで有効にすることは推奨されません

​

enable_full_text_index

別名: allow_experimental_full_text_index

true に設定すると、テキスト索引の使用が許可されます。

​

enable_global_with_statement

WITHステートメントをUNIONクエリおよびすべてのサブクエリに伝播します

​

enable_hdfs_pread

HDFS ファイルに対する pread の有効/無効を切り替えます。デフォルトでは hdfsPread が使用されます。無効にすると、HDFS ファイルの読み取りには hdfsRead と hdfsSeek が使用されます。

​

enable_http_compression

HTTPリクエストへの応答でデータの圧縮を有効または無効にします。

詳細については、HTTPインターフェイスの説明を参照してください。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

enable_identifier_resolve_cache

クエリ アナライザで識別子解決cacheを有効にします。このcacheは、同じ alias が複数回参照されたときに AST の肥大化を防ぐため、解決済みの alias ノードを共有します。結果が不正確だと疑われる場合は、false に設定してcacheを無効にしてください。

​

enable_job_stack_trace

ジョブの実行結果として例外が発生した場合に、ジョブ作成元のスタックトレースを出力します。パフォーマンスオーバーヘッドを避けるため、デフォルトでは無効です。

​

enable_join_fixed_hash_table_conversion

キーが値域の小さい単一の整数である場合に、JOIN 用の hash table をフラットな配列に変換できるようにします。

​

enable_join_runtime_filters

実行時に右側から収集した JOIN の結合キーの集合を使って、左側を絞り込みます。

​

enable_join_transitive_predicates

既存の JOIN 条件から、推移的な等値 JOIN 述語を推論します。 たとえば、A.x = B.x と B.x = C.x がある場合、A.x = C.x という述語も 追加されるため、JOIN 順序オプティマイザは直接 (A JOIN C) のプランを検討できます。

​

enable_lazy_columns_replication

JOIN および ARRAY JOIN におけるカラムの遅延レプリケーションを有効にします。これにより、同じ行をメモリ上で何度も不要にコピーするのを防げます。

​

enable_lightweight_delete

別名: allow_experimental_lightweight_delete

MergeTree テーブルに対する論理削除 DELETE ミューテーションを有効にします。

​

enable_lightweight_update

別名: allow_experimental_lightweight_update

論理更新の使用を有効にします。

​

enable_materialized_cte

マテリアライズド共通テーブル式を有効にします。enable_global_with_statement よりも優先されます

​

enable_memory_bound_merging_of_aggregation_results

集約のためのメモリ制約付きマージ戦略を有効にします。

​

enable_multiple_prewhere_read_steps

WHERE から PREWHERE により多くの条件を移し、AND で結合された複数の条件がある場合は、ディスクからの読み取りとフィルタリングを複数のステップで行います

​

enable_named_columns_in_function_tuple

すべての名前が一意で、引用符なしの識別子として扱える場合、tuple() 関数で名前付きタプルを生成します。

​

enable_optimize_predicate_expression

SELECT クエリでプレディケートプッシュダウンを有効にします。

プレディケートプッシュダウンにより、分散クエリのネットワークトラフィックを大幅に削減できる場合があります。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

使用方法

次のクエリを考えてみましょう:

1. SELECT count() FROM test_table WHERE date = '2018-10-10'
2. SELECT count() FROM (SELECT * FROM test_table) WHERE date = '2018-10-10'

enable_optimize_predicate_expression = 1 の場合、ClickHouse は処理時に WHERE をサブクエリへ適用するため、これらのクエリの実行時間は同じになります。

enable_optimize_predicate_expression = 0 の場合、2 番目のクエリの実行時間はかなり長くなります。これは、サブクエリの完了後に WHERE 句がすべてのデータに適用されるためです。

​

enable_optimize_predicate_expression_to_final_subquery

述語を FINAL サブクエリにプッシュダウンすることを許可します。

​

enable_order_by_all

ORDER BY ALL 構文でのソートを有効または無効にします。詳しくは ORDER BY を参照してください。

設定可能な値:

• 0 — ORDER BY ALL を無効にします。
• 1 — ORDER BY ALL を有効にします。

例

クエリ:

CREATE TABLE TAB(C1 Int, C2 Int, ALL Int) ENGINE=Memory();

INSERT INTO TAB VALUES (10, 20, 30), (20, 20, 10), (30, 10, 20);

SELECT * FROM TAB ORDER BY ALL; -- ALL が曖昧であるというエラーを返す

SELECT * FROM TAB ORDER BY ALL SETTINGS enable_order_by_all = 0;

結果:

┌─C1─┬─C2─┬─ALL─┐
│ 20 │ 20 │  10 │
│ 30 │ 10 │  20 │
│ 10 │ 20 │  30 │
└────┴────┴─────┘

​

enable_parallel_blocks_marshalling

分散クエリにのみ影響します。有効にすると、ブロックはイニシエーターへの送信前後に、パイプラインスレッドでシリアライズ／デシリアライズおよび圧縮／伸長されます (つまり、デフォルトよりも高い並列度で処理されます) 。

​

enable_parsing_to_custom_serialization

true の場合、テーブルから取得したシリアライゼーションのヒントに従って、データをカスタムシリアライゼーション (例: スパース) を持つカラムに直接パースできます。

​

enable_positional_arguments

GROUP BY、LIMIT BY、ORDER BY ステートメントで、位置引数のサポートを有効または無効にします。

設定可能な値:

• 0 — 位置引数はサポートされません。
• 1 — 位置引数がサポートされます。カラム名の代わりにカラム番号を使用できます。

例

クエリ:

CREATE TABLE positional_arguments(one Int, two Int, three Int) ENGINE=Memory();

INSERT INTO positional_arguments VALUES (10, 20, 30), (20, 20, 10), (30, 10, 20);

SELECT * FROM positional_arguments ORDER BY 2,3;

結果:

┌─one─┬─two─┬─three─┐
│  30 │  10 │   20  │
│  20 │  20 │   10  │
│  10 │  20 │   30  │
└─────┴─────┴───────┘

​

enable_positional_arguments_for_projections

PROJECTION 定義で位置引数をサポートするかどうかを切り替えます。あわせて、enable_positional_arguments 設定も参照してください。

これは上級者向けの設定です。ClickHouse を使い始めたばかりであれば、変更しないでください。

設定可能な値:

• 0 — 位置引数はサポートされません。
• 1 — 位置引数がサポートされます。カラム名の代わりにカラム番号を使用できます。

​

enable_producing_buckets_out_of_order_in_aggregation

メモリ効率の高い集約 (distributed_aggregation_memory_efficient を参照) で、バケットを順不同で生成できるようにします。 これにより、集約バケットのサイズに偏りがある場合、レプリカは小さい id の重いバケットをまだ処理している間でも、より大きい id のバケットをイニシエーターに送信できるため、パフォーマンスが向上する可能性があります。 欠点として、メモリ使用量が増える可能性があります。

​

enable_reads_from_query_cache

有効にすると、SELECT クエリの結果は query cache から取得されます。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

enable_s3_requests_logging

S3 リクエストの非常に詳細なログを有効にします。デバッグ時にのみ有用です。

​

enable_scalar_subquery_optimization

true に設定すると、スカラーサブクエリで大きなスカラー値のシリアライズ／デシリアライズを防ぎ、同じサブクエリが複数回実行されるのを回避できる場合があります。

​

enable_scopes_for_with_statement

無効にすると、親の WITH 句内の宣言は、現在のスコープ内で宣言された場合と同じスコープで動作します。

これはアナライザの互換性設定であり、旧アナライザで実行できていた一部の無効なクエリを実行できるようにするためのものです。

​

enable_sharding_aggregator

グループ化キーのハッシュに基づいて行をスレッド間に分散し、各スレッドがマージフェーズなしで重複しないキーの部分集合を集約できるようにする、分片化された GROUP BY 最適化を有効にします。

これは、データが均等に分散した高カーディナリティのキーに対しては効率的ですが、キー分布の偏りが大きい場合や、異なるキーがごく少ないクエリでは性能が低下することがあります。

設定可能な値:

• 0 — 分片化された集約の最適化は無効です。
• 1 — 分片化された集約の最適化は有効です。

​

enable_shared_storage_snapshot_in_query

有効にすると、1 つのクエリ内のすべてのサブクエリで、各テーブルの同じ StorageSnapshot が共有されます。 これにより、同じテーブルに複数回アクセスする場合でも、クエリ全体でデータの一貫したビューが確保されます。

これは、データパーツの内部整合性が重要なクエリで必要です。例:

SELECT
    count()
FROM events
WHERE (_part, _part_offset) IN (
    SELECT _part, _part_offset
    FROM events
    WHERE user_id = 42
)

この設定がない場合、外側のクエリと内側のクエリが異なるデータスナップショットに対して実行される可能性があり、誤った結果につながるおそれがあります。

この設定を有効にすると、プランニング段階の完了後にスナップショットから不要なデータパーツを取り除く最適化が無効になります。 その結果、長時間実行されるクエリでは、廃止されたパーツがクエリの実行中ずっと保持される可能性があり、パーツのクリーンアップが遅れ、ストレージへの負荷が増大します。

現在、この設定が適用されるのは MergeTree family のテーブルのみです。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

enable_sharing_sets_for_mutations

同じミューテーション内の異なるタスク間で、IN サブクエリ用に構築された Set オブジェクトを共有できるようにします。これにより、メモリ使用量と CPU 使用量が削減されます

​

enable_software_prefetch_in_aggregation

集計でのソフトウェアプリフェッチの使用を有効にします

​

enable_software_prefetch_in_join

大規模なハッシュテーブルでのメモリアクセス遅延を隠すため、ハッシュ結合のプローブフェーズでソフトウェアプリフェッチを使用できるようにします。

​

enable_streaming_queries

SELECT ... FROM t STREAM [CURSOR '{...}'] の継続的クエリを許可します。 オフの場合、STREAM 修飾子を使用するあらゆるテーブル式は プラン構築時に拒否されます。これは streaming-queries 機能全体を有効化するための包括的な設定であり、追加の機能はそれぞれ独自の設定で制御される場合があります。

​

enable_time_time64_type

別名: allow_experimental_time_time64_type

Time および Time64 データ型を作成できるようになります。

​

enable_unaligned_array_join

サイズの異なる複数の配列に対する ARRAY JOIN を許可します。この設定を有効にすると、配列は最も長い配列に合わせてリサイズされます。

​

enable_url_encoding

URL エンジンのテーブルで、uri 内のパスのデコード/エンコードを有効または無効にできます。

デフォルトでは無効です。

​

enable_vertical_final

有効にすると、FINAL 時に重複した行を削除済みとしてマークし、行をマージする代わりに後でそれらをフィルタリングして除去します

​

enable_writes_to_query_cache

有効にすると、SELECT クエリの結果が query cache に保存されます。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

enforce_strict_identifier_format

有効にすると、英数字とアンダースコアのみで構成された識別子だけを許可します。

​

engine_file_allow_create_multiple_files

フォーマットに接尾辞 (JSON、ORC、Parquet など) がある場合、Fileエンジンのテーブルで insert のたびに新しいファイルを作成するかどうかを有効または無効にします。有効にすると、insert のたびに次のパターンに従った名前で新しいファイルが作成されます。

data.Parquet -> data.1.Parquet -> data.2.Parquet, etc.

設定可能な値:

• 0 — INSERT クエリは新しいデータをファイルの末尾に追加します。
• 1 — INSERT クエリは新しいファイルを作成します。

​

engine_file_empty_if_not_exists

ファイルが存在しない場合でも、file engineテーブルからデータを選択できるようにします。

設定可能な値:

• 0 — SELECT は例外をスローします。
• 1 — SELECT は空の結果を返します。

​

engine_file_skip_empty_files

File エンジンのテーブルで、空のファイルをスキップするかどうかを有効または無効にします。

設定可能な値:

• 0 — 空のファイルが要求されたフォーマットと互換性がない場合、SELECT は例外を返します。
• 1 — 空のファイルに対して SELECT は空の結果を返します。

​

engine_file_truncate_on_insert

File エンジンのテーブルで、insert の前に truncate を実行するかどうかを有効または無効にします。

設定可能な値:

• 0 — INSERT クエリは新しいデータをファイルの末尾に追記します。
• 1 — INSERT クエリはファイルの既存の内容を新しいデータで置き換えます。

​

engine_url_skip_empty_files

URL エンジンのテーブルで、空のファイルをスキップするかどうかを設定します。

設定可能な値:

• 0 — 空のファイルが要求されたフォーマットに対応していない場合、SELECT は例外をスローします。
• 1 — 空のファイルに対して、SELECT は空の結果を返します。

​

exact_rows_before_limit

有効にすると、ClickHouse は rows_before_limit_at_least 統計について正確な値を返しますが、その代わり、limit に達するまでのデータをすべて読み取る必要があります

​

except_default_mode

EXCEPT クエリのデフォルトモードを設定します。設定可能な値: 空文字列、‘ALL’、‘DISTINCT’。空文字列の場合、モードを指定しないクエリは例外を返します。

​

exclude_materialize_skip_indexes_on_insert

指定したスキップ索引を、INSERT 時に構築・保存の対象から除外します。除外されたスキップ索引は、マージ時または明示的な MATERIALIZE INDEXクエリによって引き続き構築・保存されます。

materialize_skip_indexes_on_insert が false の場合は、効果がありません。

例:

CREATE TABLE tab
(
    a UInt64,
    b UInt64,
    INDEX idx_a a TYPE minmax,
    INDEX idx_b b TYPE set(3)
)
ENGINE = MergeTree ORDER BY tuple();

SET exclude_materialize_skip_indexes_on_insert='idx_a'; -- idx_a は INSERT 時に更新されない
--SET exclude_materialize_skip_indexes_on_insert='idx_a, idx_b'; -- どちらの索引も INSERT 時に更新されない

INSERT INTO tab SELECT number, number / 50 FROM numbers(100); -- idx_b のみ更新される

-- セッション設定であるため、クエリ単位で設定できる
INSERT INTO tab SELECT number, number / 50 FROM numbers(100, 100) SETTINGS exclude_materialize_skip_indexes_on_insert='idx_b';

ALTER TABLE tab MATERIALIZE INDEX idx_a; -- このクエリで索引を明示的にマテリアライズできる

SET exclude_materialize_skip_indexes_on_insert = DEFAULT; -- 設定をデフォルトにリセットする

​

execute_exists_as_scalar_subquery

非相関の EXISTS サブクエリを、スカラーサブクエリとして実行します。スカラーサブクエリと同様に cache が使用され、結果には定数畳み込みが適用されます。

Cloud でのデフォルト値: 0.

​

external_storage_connect_timeout_sec

接続タイムアウト (単位: 秒) 。現在サポートされているのは MySQL のみです

​

external_storage_max_read_bytes

外部エンジンを持つテーブルが履歴データをフラッシュする際の最大バイト数を制限します。現在サポートされているのは、MySQLテーブルエンジン、データベースエンジン、およびDictionaryのみです。0 の場合、この設定は無効です

​

external_storage_max_read_rows

外部エンジンを使用するテーブルで履歴データをフラッシュする際の、最大行数を制限します。現在サポートされているのは、MySQL table engine、データベースエンジン、および Dictionary のみです。0 の場合、この設定は無効です

​

external_storage_rw_timeout_sec

読み取り/書き込みのタイムアウト (秒) 。現在サポートされているのは MySQL のみです

​

external_table_functions_use_nulls

mysql、postgresql、および odbc のテーブル関数で Nullable カラムをどのように扱うかを定義します。

設定可能な値:

• 0 — テーブル関数は Nullable カラムを明示的に使用します。
• 1 — テーブル関数は Nullable カラムを暗黙的に使用します。

使用方法

この設定を 0 にすると、テーブル関数は Nullable カラムを作成せず、NULL の代わりにデフォルト値を挿入します。これは Array 内の NULL 値にも適用されます。

​

external_table_strict_query

true に設定されている場合、外部テーブルへのクエリで式をローカルフィルタに変換することは禁止されます。

​

extract_key_value_pairs_max_pairs_per_row

別名: extract_kvp_max_pairs_per_row

extractKeyValuePairs 関数で生成できるペアの最大数。メモリの過剰消費を防ぐための保護措置として使用されます。

​

extremes

極値 (クエリ結果のカラムにおける最小値および最大値) を計算するかどうかを指定します。0 または 1 を指定できます。デフォルトは 0 (無効) です。 詳細については、「Extreme values」セクションを参照してください。

​

fallback_to_stale_replicas_for_distributed_queries

更新済みのデータが利用できない場合に、古いレプリカへクエリを強制的に送ります。レプリケーション を参照してください。

ClickHouse は、テーブルの古いレプリカの中から最も適切なものを選択します。

レプリケートテーブルを参照する分散テーブルに対して SELECT を実行する際に使用されます。

デフォルト値は 1 (enabled) です。

​

file_like_engine_default_partition_strategy

ファイルライクなエンジンのデフォルトのパーティション方式。

​

filesystem_cache_allow_background_download

ファイルシステムキャッシュで、リモートストレージから読み取ったデータのバックグラウンドダウンロードをキューに入れられるようにします。無効にすると、現在のクエリ/セッションではダウンロードはフォアグラウンドで実行されます。

​

filesystem_cache_boundary_alignment

ファイルシステムキャッシュの境界アラインメントです。この設定は、ディスク以外からの読み取りにのみ適用されます (たとえば、remote table engines / table function の cache には適用されますが、MergeTree テーブルのストレージ構成には適用されません) 。値が 0 の場合は、アラインメントは行われません。

​

filesystem_cache_enable_background_download_during_fetch

ClickHouse Cloud でのみ有効です。ファイルシステムキャッシュで領域を確保するために cache をロックするまでの待機時間

​

filesystem_cache_enable_background_download_for_metadata_files_in_packed_storage

ClickHouse Cloud でのみ有効です。ファイルシステムキャッシュで領域を予約する際に、キャッシュのロック取得を待機する時間

​

filesystem_cache_max_download_size

1回のクエリでダウンロードできるリモートファイルシステムキャッシュの最大サイズ

​

filesystem_cache_name

ステートレスなテーブルエンジンまたはデータレイクで使用するファイルシステムキャッシュの名前

​

filesystem_cache_prefer_bigger_buffer_size

ファイルシステムキャッシュが有効な場合、cache のパフォーマンスを低下させる小さなファイルセグメントの書き込みを避けるため、より大きなバッファサイズを優先します。一方、この設定を有効にすると、メモリ使用量が増加する可能性があります。

​

filesystem_cache_reserve_space_wait_lock_timeout_milliseconds

ファイルシステムキャッシュで領域を予約する際にキャッシュをロックするまでの待機時間

​

filesystem_cache_segments_batch_size

読み取りバッファが cache に要求できる、1 回のバッチに含まれるファイルセグメント数の上限です。値が小さすぎると cache への要求が過剰になり、大きすぎると cache からのエビクションが遅くなる可能性があります

​

filesystem_cache_skip_download_if_exceeds_per_query_cache_write_limit

別名: skip_download_if_exceeds_query_cache

クエリ cache のサイズを超える場合、リモートファイルシステムからのダウンロードをスキップします

​

filesystem_prefetch_max_memory_usage

prefetch の最大メモリ使用量です。

Cloud でのデフォルト値: 総メモリの 10%。

​

filesystem_prefetch_step_bytes

バイト単位の prefetch step です。ゼロは auto を意味します。おおよそ最適な prefetch step が自動的に推定されますが、必ずしも 100% 最適になるとは限りません。実際の値は、設定 filesystem_prefetch_min_bytes_for_single_read_task によって異なる場合があります。

​

filesystem_prefetch_step_marks

mark 単位の先読みステップです。0 は auto を意味し、ほぼ最適な先読みステップが自動的に推定されますが、必ずしも 100% 最適になるとは限りません。実際の値は、設定 filesystem_prefetch_min_bytes_for_single_read_task によって異なる場合があります

​

filesystem_prefetches_limit

prefetch の最大数です。0 は無制限を意味します。prefetch の数を制限したい場合は、設定 filesystem_prefetches_max_memory_usage を使用することを推奨します

​

final

クエリ内のすべてのテーブル、および FINAL を適用できるテーブル (JOIN されたテーブル、サブクエリ内のテーブル、分散テーブルを含む) に対して、FINAL 修飾子を自動的に適用します。

設定可能な値:

• 0 - 無効
• 1 - 有効

例:

CREATE TABLE test
(
    key Int64,
    some String
)
ENGINE = ReplacingMergeTree
ORDER BY key;

INSERT INTO test FORMAT Values (1, 'first');
INSERT INTO test FORMAT Values (1, 'second');

SELECT * FROM test;
┌─key─┬─some───┐
│   1 │ second │
└─────┴────────┘
┌─key─┬─some──┐
│   1 │ first │
└─────┴───────┘

SELECT * FROM test SETTINGS final = 1;
┌─key─┬─some───┐
│   1 │ second │
└─────┴────────┘

SET final = 1;
SELECT * FROM test;
┌─key─┬─some───┐
│   1 │ second │
└─────┴────────┘

​

finalize_projection_parts_synchronously

有効にすると、projection parts は INSERT 中に同期的にファイナライズされ、S3 アップロードの並列度は下がるものの、ピークメモリ使用量を削減できます。デフォルトでは、各 projection の出力ストリームは、パーツ全体 (すべての projections を含む) がファイナライズされるまで保持されます。これにより S3 アップロードを並行して進められますが、ピークメモリ使用量は projections の数に比例して増加します。この設定が影響するのは INSERT パスのみです。merge と mutation では、projections はすでに同期的にファイナライズされます。

​

flatten_nested

nested カラムのデータフォーマットを設定します。

設定可能な値:

• 1 — Nested カラムは個別の配列にフラット化されます。
• 0 — Nested カラムはタプルの単一の配列のままになります。

使用方法

この設定を 0 にすると、任意のネストレベルを使用できます。

例

クエリ:

SET flatten_nested = 1;
CREATE TABLE t_nest (`n` Nested(a UInt32, b UInt32)) ENGINE = MergeTree ORDER BY tuple();

SHOW CREATE TABLE t_nest;

結果:

┌─statement───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.t_nest
(
    `n.a` Array(UInt32),
    `n.b` Array(UInt32)
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS index_granularity = 8192 │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

クエリ:

SET flatten_nested = 0;

CREATE TABLE t_nest (`n` Nested(a UInt32, b UInt32)) ENGINE = MergeTree ORDER BY tuple();

SHOW CREATE TABLE t_nest;

結果:

┌─statement──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.t_nest
(
    `n` Nested(a UInt32, b UInt32)
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS index_granularity = 8192 │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

​

force_aggregate_partitions_independently

適用可能であってもヒューリスティクスによって使用しないと判断された場合に、この最適化を強制的に使用します

​

force_aggregation_in_order

この設定は、分散クエリをサポートするためにサーバー内部で使用されます。通常の動作に支障をきたすため、手動で変更しないでください。 (分散集約時に、リモートノードで順序どおりの集約の使用を強制します。)

​

force_data_skipping_indices

指定されたデータスキッピングインデックスが使用されていない場合、クエリの実行を無効にします。

次の例を見てみましょう。

CREATE TABLE data
(
    key Int,
    d1 Int,
    d1_null Nullable(Int),
    INDEX d1_idx d1 TYPE minmax GRANULARITY 1,
    INDEX d1_null_idx assumeNotNull(d1_null) TYPE minmax GRANULARITY 1
)
Engine=MergeTree()
ORDER BY key;

SELECT * FROM data_01515;
SELECT * FROM data_01515 SETTINGS force_data_skipping_indices=''; -- クエリはCANNOT_PARSE_TEXTエラーを生成します。
SELECT * FROM data_01515 SETTINGS force_data_skipping_indices='d1_idx'; -- クエリはINDEX_NOT_USEDエラーを生成します。
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='d1_idx'; -- OK。
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='`d1_idx`'; -- OK（フル機能パーサーの使用例）。
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='`d1_idx`, d1_null_idx'; -- d1_null_idxが使用されていないため、クエリはINDEX_NOT_USEDエラーを生成します。
SELECT * FROM data_01515 WHERE d1 = 0 AND assumeNotNull(d1_null) = 0 SETTINGS force_data_skipping_indices='`d1_idx`, d1_null_idx'; -- OK。

​

force_grouping_standard_compatibility

GROUPING関数が、引数が集約キーとして使われていない場合に 1 を返すようにします

​

force_index_by_date

日付による索引を使用できない場合、クエリを実行できないようにします。

MergeTree family のテーブルで機能します。

force_index_by_date=1 の場合、ClickHouse はクエリに、データ範囲の絞り込みに使用できる日付キー条件があるかどうかを確認します。適切な条件がない場合は、例外をスローします。ただし、その条件によって読み取るデータ量が実際に減るかどうかまでは確認しません。たとえば、条件 Date != ' 2000-01-01 ' は、テーブル内のすべてのデータに一致する場合でも有効です (つまり、クエリの実行には全件スキャンが必要です) 。MergeTree テーブルにおけるデータ範囲の詳細については、MergeTree を参照してください。

​

force_optimize_projection

プロジェクションの最適化が有効な場合 (optimize_use_projections 設定を参照) 、SELECT クエリで プロジェクション を必ず使用するかどうかを有効または無効にします。

設定可能な値:

• 0 — プロジェクションの最適化は必須ではありません。
• 1 — プロジェクションの最適化は必須です。

​

force_optimize_projection_name

空でない文字列が設定されている場合、このプロジェクションがクエリ内で少なくとも1回使用されていることを確認します。

設定可能な値:

• string: クエリで使用されるプロジェクション名

​

force_optimize_skip_unused_shards

optimize_skip_unused_shards が有効で、かつ未使用の分片をスキップできない場合に、クエリ実行を許可するかどうかを制御します。スキップできず、この設定が有効な場合は、例外がスローされます。

設定可能な値:

• 0 — 無効。ClickHouse は例外をスローしません。
• 1 — 有効。テーブルに分片キーがある場合にのみ、クエリ実行が無効になります。
• 2 — 有効。テーブルに分片キーが定義されているかどうかにかかわらず、クエリ実行が無効になります。

​

force_optimize_skip_unused_shards_nesting

分散クエリのネストレベルに応じて force_optimize_skip_unused_shards の適用範囲を制御します (この設定を有効にするには、force_optimize_skip_unused_shards も有効である必要があります) 。これは、ある Distributed テーブルが別の Distributed テーブルを参照する場合に該当します。

設定可能な値:

• 0 - 無効。force_optimize_skip_unused_shards は常に動作します。
• 1 — force_optimize_skip_unused_shards を第1レベルでのみ有効にします。
• 2 — force_optimize_skip_unused_shards を第2レベルまで有効にします。

​

force_primary_key

主キーによる索引を利用できない場合、クエリの実行を無効にします。

MergeTree family のテーブルで動作します。

force_primary_key=1 の場合、ClickHouse はクエリに、データ範囲の絞り込みに使用できる主キー条件があるかどうかを確認します。適切な条件がない場合は、例外をスローします。ただし、その条件によって読み取るデータ量が減るかどうかまでは確認しません。MergeTree テーブルにおけるデータ範囲の詳細については、MergeTree を参照してください。

​

force_remove_data_recursively_on_drop

DROP クエリ実行時にデータを再帰的に削除します。これにより ‘Directory not empty’ エラーは回避できますが、デタッチされたデータも気付かないうちに削除される可能性があります

​

formatdatetime_e_with_space_padding

関数 formatDateTime のフォーマッタ ‘%e’ は、1 桁の日を先頭にスペースを付けて出力します。たとえば、‘2’ ではなく ’ 2’ と出力されます。

​

formatdatetime_f_prints_scale_number_of_digits

関数 ‘formatDateTime’ のフォーマッタ ‘%f’ は、固定の 6 桁ではなく、DateTime64 の scale で指定された桁数だけを出力します。

​

formatdatetime_f_prints_single_zero

関数 ‘formatDateTime’ のフォーマッタ ‘%f’ は、フォーマット対象の値に小数秒がない場合、6 個のゼロではなく 1 個のゼロを出力します。

​

formatdatetime_format_without_leading_zeros

関数 formatDateTime のフォーマッタ %c、%l、%k は、月と時を先頭のゼロなしで出力します。

​

formatdatetime_parsedatetime_m_is_month_name

関数 formatDateTime および parseDateTime におけるフォーマッタ %M は、分ではなく月名を出力・解析します。

​

fsync_metadata

.sql ファイルの書き込み時に fsync を有効または無効にします。デフォルトでは有効です。

server に数百万もの小さな table があり、それらが絶えず作成・削除されている場合は、これを無効にするのが適切です。

​

function_base58_max_input_size

関数 base58Encode、base58Decode、tryBase58Decode に対する、単一の入力値の最大サイズ (バイト単位) です。汎用的な base58 変換は入力長に対して二次時間であるため、1 つの大きな値だけでも非常に長時間実行されることがあります。base58 は短いデータ (キー、ハッシュ、アドレス) 向けであり、既定値の 10 KB は十分に余裕のある安全しきい値です。base58Encode と base58Decode は、これを超える入力に対して TOO_LARGE_STRING_SIZE を送出し、tryBase58Decode は空文字列を返します。値 0 を指定すると制限は無効になります (この設定が導入される前の動作になります) 。線形の base32 関数と base64 関数には影響しません。

​

function_date_trunc_return_type_behavior

dateTrunc 関数の戻り値の型の動作を変更できます。

設定可能な値:

• 0 - 2 番目の引数が DateTime64/Date32 の場合、戻り値の型は最初の引数の時間単位にかかわらず DateTime64/Date32 になります。
• 1 - Date32 の場合、結果は常に Date になります。DateTime64 の場合、時間単位が second 以上であれば結果は DateTime になります。

​

function_implementation

特定のターゲットまたはバリアント向けの関数実装を選択します (実験的) 。空の場合は、すべて有効になります。

​

function_json_value_return_type_allow_complex

json_value 関数が複合型 (struct、array、map など) を返すことを許可するかどうかを制御します。

SELECT JSON_VALUE('{"hello":{"world":"!"}}', '$.hello') settings function_json_value_return_type_allow_complex=true

┌─JSON_VALUE('{"hello":{"world":"!"}}', '$.hello')─┐
│ {"world":"!"}                                    │
└──────────────────────────────────────────────────┘

1 row in set. Elapsed: 0.001 sec.

設定可能な値:

• true — 許可します。
• false — 許可しません。

​

function_json_value_return_type_allow_nullable

JSON_VALUE 関数で値が存在しない場合に NULL を返すことを許可するかどうかを制御します。

SELECT JSON_VALUE('{"hello":"world"}', '$.b') settings function_json_value_return_type_allow_nullable=true;

┌─JSON_VALUE('{"hello":"world"}', '$.b')─┐
│ ᴺᵁᴸᴸ                                   │
└────────────────────────────────────────┘

1 row in set. Elapsed: 0.001 sec.

設定可能な値:

• true — 許可します。
• false — 許可しません。

​

function_locate_has_mysql_compatible_argument_order

関数 locate の引数の順序を制御します。

設定可能な値:

• 0 — 関数 locate は引数 (haystack, needle[, start_pos]) を受け付けます。
• 1 — 関数 locate は引数 (needle, haystack, [, start_pos]) を受け付けます (MySQL 互換の動作)

​

function_range_max_elements_in_block

関数 range が生成するデータ量の安全しきい値を設定します。データの各 block に対してこの関数が生成できる値の最大数を定義します (block 内の各行の配列サイズの合計) 。

設定可能な値:

• 正の整数。

関連項目

• max_block_size
• min_insert_block_size_rows

​

function_sleep_max_microseconds_per_block

関数 sleep が各 block ごとにスリープできる最大マイクロ秒数です。これを超える値を指定して呼び出すと、例外がスローされます。これは安全しきい値です。

​

function_visible_width_behavior

visibleWidth の動作バージョンです。0 - コードポイント数のみをカウントします。1 - ゼロ幅文字および結合文字を正しくカウントし、全角文字は 2 文字分としてカウントし、タブ幅を推定し、DEL 文字をカウントします。

​

functions_h3_default_if_invalid

false の場合、h3CellAreaM2 などの h3 関数は、入力が無効だと例外を発生させます。true の場合は、0 またはデフォルト値を返します。

​

geo_distance_returns_float64_on_float64_arguments

geoDistance、greatCircleDistance、greatCircleAngle 関数の4つの引数がすべて Float64 の場合、Float64 を返し、内部計算には倍精度を使用します。以前の ClickHouse バージョンでは、これらの関数は常に Float32 を返していました。

​

geotoh3_argument_order

関数 geoToH3 は、lon_lat に設定すると (lon, lat) を受け取り、lat_lon に設定すると (lat, lon) を受け取ります。

​

glob_expansion_max_elements

許可されるアドレスの最大数 (外部ストレージ、テーブル関数など) 。

​

grace_hash_join_initial_buckets

Grace Hash Join の初期バケット数

​

grace_hash_join_max_buckets

Grace Hash Join で使用するバケット数の上限

​

group_by_overflow_mode

集約における一意なキーの数が制限を超えた場合の動作を設定します。

• throw: 例外をスローする
• break: クエリの実行を停止し、部分的な結果を返す
• any: 集合に入ったキーについては集約を継続しますが、新しいキーは集合に追加しません。

any 値を使用すると、GROUP BY の近似結果を得られます。この近似の精度は、 データの統計的な性質に依存します。

​

group_by_two_level_threshold

キー数がこの値に達すると、二段階集約を開始します。0 の場合、しきい値は設定されません。

​

group_by_two_level_threshold_bytes

集約状態のサイズが何バイトに達すると二段階集約の使用を開始するかを指定します。0 は、しきい値が設定されていないことを意味します。少なくともいずれか 1 つのしきい値がトリガーされると、二段階集約が使用されます。

​

group_by_use_nulls

GROUP BY clause が集約キーの型をどのように扱うかを変更します。 ROLLUP、CUBE、GROUPING SETS 指定子を使用すると、一部の結果行の生成時に使用されない集約キーが生じることがあります。 これらのキーに対応するカラムは、この設定に応じて、該当する行でデフォルト値または NULL で埋められます。

設定可能な値:

• 0 — 欠けている値を表すために、集約キーの型のデフォルト値を使用します。
• 1 — ClickHouse は SQL 標準に従って GROUP BY を実行します。集約キーの型は Nullable に変換されます。対応する集約キーのカラムは、そのキーが使用されなかった行では NULL で埋められます。

関連項目:

• GROUP BY clause

​

h3togeo_lon_lat_result_order

関数 h3ToGeo は、true の場合は (lon, lat) を、そうでない場合は (lat, lon) を返します。

​

handshake_timeout_ms

ハンドシェイク中にレプリカから Hello パケットを受信するまでのタイムアウト (ミリ秒) 。

​

hdfs_create_new_file_on_insert

HDFS engine テーブルで、insert ごとに新しいファイルを作成するかどうかを切り替えます。有効にすると、insert のたびに、次のようなパターンの名前を持つ新しい HDFS ファイルが作成されます。

initial: data.Parquet.gz -> data.1.Parquet.gz -> data.2.Parquet.gz, etc.

設定可能な値:

• 0 — INSERT クエリは新しいデータをファイルの末尾に追記します。
• 1 — INSERT クエリは新しいファイルを作成します。

​

hdfs_ignore_file_doesnt_exist

特定のキーの読み取り時に、ファイルが存在しない場合はその不在を無視します。

設定可能な値:

• 1 — SELECT は空の結果を返します。
• 0 — SELECT は例外をスローします。

​

hdfs_replication

実際のレプリカ数は、HDFS ファイルの作成時に指定できます。

​

hdfs_skip_empty_files

HDFS エンジンのテーブルで、空のファイルのスキップを有効または無効にします。

設定可能な値:

• 0 — 空のファイルが指定されたフォーマットと互換性がない場合、SELECT は例外をスローします。
• 1 — 空のファイルに対して SELECT は空の結果を返します。

​

hdfs_throw_on_zero_files_match

glob 展開ルールに従って一致するファイルが 0 件の場合に、エラーをスローします。

設定可能な値:

• 1 — SELECT は例外をスローします。
• 0 — SELECT は空の結果を返します。

​

hdfs_truncate_on_insert

HDFS engine テーブルで、insert の前に切り詰めを行うかどうかを有効または無効にします。無効にすると、HDFS 内にファイルがすでに存在する状態で insert を試みた場合、例外がスローされます。

設定可能な値:

• 0 — INSERT クエリは新しいデータをファイルの末尾に追記します。
• 1 — INSERT クエリはファイルの既存の内容を新しいデータで置き換えます。

​

hedged_connection_timeout_ms

ヘッジドリクエストでレプリカへの接続を確立する際の接続タイムアウト

​

highlight_max_matches_per_row

highlight 関数で、各行におけるハイライト一致数の最大値を設定します。大きなテキスト内で反復の多いパターンをハイライトする際に、過剰なメモリ使用を防ぐために使用します。

設定可能な値:

• 正の整数。

​

hnsw_candidate_list_size_for_search

ベクトル類似度索引の検索時における動的な候補リストのサイズです。ef_search とも呼ばれます。

​

hsts_max_age

HSTS の有効期限です。0 は HSTS を無効にすることを意味します。

​

http_connection_timeout

HTTP 接続のタイムアウト時間 (秒) 。

設定可能な値:

• 任意の正の整数。
• 0 - 無効 (無期限) 。

​

http_headers_progress_interval_ms

HTTP headers X-ClickHouse-Progress は、指定した各間隔より短い頻度では送信されません。

​

http_headers_read_timeout

すべてのHTTPリクエストヘッダーを読み取るための最大時間 (秒) です。これはヘッダー全体のパース処理に対する合計の制限時間であり、読み取りごとのタイムアウトではありません。クライアントがヘッダーデータを少しずつ送信して接続を開いたままにする、slowloris型の攻撃を防ぎます。

​

http_make_head_request

http_make_head_request 設定では、HTTP からデータを読み取る際に HEAD リクエストを実行し、サイズなど、読み取る対象のファイルに関する情報を取得できます。既定で有効になっているため、サーバーが HEAD リクエストをサポートしていない場合は、この設定を無効にすることを検討してください。

​

http_max_field_name_size

HTTPリクエストヘッダー、クエリパラメータ、フォームデータ内のフィールド名の最大長。

​

http_max_field_value_size

HTTPリクエストヘッダー、クエリパラメータ、およびフォームデータ内のフィールド値の最大長。

​

http_max_fields

HTTPリクエストヘッダー、クエリパラメータ、およびフォームデータ内のフィールドの最大数

​

http_max_multipart_form_data_size

multipart/form-data コンテンツのサイズ上限です。この設定は URL パラメータからは解析できないため、ユーザープロファイルで設定する必要があります。なお、クエリの実行が始まる前に、コンテンツはメモリ上で解析され、外部テーブルが作成されます。また、この段階に影響する制限はこれだけです (max memory usage と max execution time の制限は、HTTP フォームデータの読み取り中には効きません) 。

​

http_max_request_header_size

すべてのHTTPリクエストヘッダーの最大合計サイズ (名前と値の合計) をバイト単位で指定します。

​

http_max_request_param_data_size

定義済みのHTTPリクエストでクエリパラメータとして使用されるリクエストデータのサイズ上限。

​

http_max_tries

HTTP 経由で読み取る際の最大試行回数。

​

http_max_uri_size

HTTP request の URI の最大長を設定します。

設定可能な値:

• 正の整数。

​

http_native_compression_disable_checksumming_on_decompress

クライアントからの HTTP POST データの伸長時に、チェックサムの検証を有効または無効にします。ClickHouse のネイティブ圧縮フォーマットでのみ使用されます (gzip や deflate では使用されません) 。

詳細については、HTTP インターフェイスの説明を参照してください。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

http_receive_timeout

HTTP の受信タイムアウト (秒) 。

設定可能な値:

• 任意の正の整数。
• 0 - 無効 (無期限) 。

​

http_response_buffer_size

クライアントに HTTP レスポンスを送信する前、または (http_wait_end_of_query が有効な場合に) ディスクにフラッシュする前に、サーバーのメモリにバッファするバイト数。

​

http_response_headers

クエリが正常に成功した結果を含むレスポンスについて、サーバーが返す HTTP ヘッダーを追加または上書きできます。 これは HTTP インターフェイスにのみ影響します。

ヘッダーがデフォルトですでに設定されている場合は、指定した値で上書きされます。 ヘッダーがデフォルトで設定されていない場合は、ヘッダーの一覧に追加されます。 サーバーによってデフォルトで設定され、この設定で上書きされていないヘッダーは、そのまま維持されます。

この設定では、ヘッダーに定数値を設定できます。現在のところ、動的に計算された値をヘッダーに設定する方法はありません。

名前にも値にも ASCII 制御文字を含めることはできません。

ユーザーが設定を変更でき、同時に返されたヘッダーに基づいて判断も行う UI アプリケーションを実装する場合は、この設定を readonly に制限することを推奨します。

例: SET http_response_headers = '{"Content-Type": "image/png"}'

​

http_retry_initial_backoff_ms

http 経由の読み取りを再試行する際の backoff の最小値 (ミリ秒)

​

http_retry_max_backoff_ms

http 経由の読み取りを再試行する際の backoff の最大時間 (ミリ秒)

​

http_send_timeout

HTTP の送信タイムアウト (秒単位) 。

設定可能な値:

• 任意の正の整数。
• 0 - 無効 (タイムアウトなし) 。

これはデフォルトプロファイルにのみ適用されます。変更を有効にするにはサーバーの再起動が必要です。

​

http_skip_not_found_url_for_globs

HTTP_NOT_FOUND エラーが発生した glob の URL をスキップします

​

http_wait_end_of_query

サーバー側で HTTP レスポンスのバッファリングを有効にします。

​

http_write_exception_in_output_format

有効な出力を生成できるよう、例外を出力フォーマットに従って書き出します。JSON および XML フォーマットで動作します。

​

http_zlib_compression_level

enable_http_compression = 1 の場合、HTTPリクエストに対するレスポンスのデータ圧縮レベルを設定します。

設定可能な値: 1 から 9 までの数値。

​

iceberg_compaction_data_cleanup

この時間を過ぎると、データは削除されます。

​

iceberg_compaction_delay_bias

2 回のバックグラウンド compaction 操作の間に必要な最小遅延時間。

​

iceberg_data_file_size_lower_threshold_compaction

Iceberg で compaction の対象となるデータファイルのしきい値。

​

iceberg_data_file_size_upper_threshold_compaction

Iceberg における compaction のデータファイルのしきい値。

​

iceberg_delete_data_on_drop

drop 時にすべての Iceberg ファイルを削除するかどうか。

​

iceberg_expire_default_max_ref_age_ms

Iceberg テーブルのプロパティ history.expire.max-ref-age-ms が存在しない場合に、expire_snapshots で使用されるデフォルト値。

​

iceberg_expire_default_max_snapshot_age_ms

このプロパティが存在しない場合に expire_snapshots が使用する、Iceberg テーブルのプロパティ history.expire.max-snapshot-age-ms のデフォルト値です。

​

iceberg_expire_default_min_snapshots_to_keep

このプロパティがない場合に expire_snapshots で使用される、Iceberg テーブルのプロパティ history.expire.min-snapshots-to-keep のデフォルト値です。

​

iceberg_insert_max_bytes_in_data_file

INSERT 操作時の Iceberg Parquet データファイルの最大バイト数。

​

iceberg_insert_max_partitions

Iceberg テーブルエンジンで 1 回の挿入操作あたりに許可されるパーティション数の最大値。

​

iceberg_insert_max_rows_in_data_file

INSERT 時の Iceberg Parquet データファイル 1 つあたりの最大行数。

​

iceberg_max_number_datafiles_to_compact

Iceberg における compaction 対象のデータファイル数のしきい値です。

​

iceberg_metadata_compression_method

.metadata.json ファイルの圧縮方法です。

​

iceberg_metadata_log_level

system.iceberg_metadata_log に出力される、Icebergテーブルのメタデータのログレベルを制御します。 通常、この設定はデバッグ目的で変更できます。

設定可能な値:

• none - メタデータログを出力しません。
• metadata - ルートの metadata.json ファイル。
• manifest_list_metadata - 上記すべて + snapshot に対応する avro マニフェストリストのメタデータ。
• manifest_list_entry - 上記すべて + avro マニフェストリストのエントリ。
• manifest_file_metadata - 上記すべて + 走査した avro マニフェストファイルのメタデータ。
• manifest_file_entry - 上記すべて + 走査した avro マニフェストファイルのエントリ。

​

iceberg_metadata_staleness_ms

0 以外の場合、指定された staleness ウィンドウより新しいキャッシュ済みのメタデータスナップショットがあれば、リモートカタログから Iceberg メタデータを取得しません。0 の場合は、常にリモートカタログから最新のメタデータバージョンを取得します。この設定を 0 以外にすると、読み取り操作のレイテンシを下げる代わりに、古いメタデータを許容することになります。

​

iceberg_orphan_files_older_than_seconds

Iceberg テーブルで孤立ファイルを削除する際の、デフォルトの経過時間しきい値 (秒) です。これより新しいファイルは孤立ファイルと見なされません。remove_orphan_files() プロシージャ呼び出しで older_than 引数が省略された場合に使用されます。デフォルトは 259200 (3日) です。

​

iceberg_snapshot_id

特定のスナップショット ID を指定して Iceberg テーブルをクエリします。

​

iceberg_timestamp_ms

特定のタイムスタンプ時点で有効だったスナップショットを使用して、Icebergテーブルをクエリします。

​

idle_connection_timeout

指定した秒数が経過したアイドル状態のTCP接続を閉じるまでのタイムアウトです。

設定可能な値:

• 正の整数 (0 の場合は 0 秒後にただちに閉じる) 。

​

ignore_cold_parts_seconds

ClickHouse Cloud でのみ有効です。新しいデータパーツは、事前にウォームアップされる (cache_populated_by_fetch を参照) か、ここで指定した秒数が経過するまで、SELECT クエリの対象から除外されます。Replicated-/SharedMergeTree でのみ有効です。

​

ignore_data_skipping_indices

クエリで使用される場合は、指定したスキッピング索引を無視します。

次の例を見てみましょう：

CREATE TABLE data
(
    key Int,
    x Int,
    y Int,
    INDEX x_idx x TYPE minmax GRANULARITY 1,
    INDEX y_idx y TYPE minmax GRANULARITY 1,
    INDEX xy_idx (x,y) TYPE minmax GRANULARITY 1
)
Engine=MergeTree()
ORDER BY key;

INSERT INTO data VALUES (1, 2, 3);

SELECT * FROM data;
SELECT * FROM data SETTINGS ignore_data_skipping_indices=''; -- クエリはCANNOT_PARSE_TEXTエラーを返します。
SELECT * FROM data SETTINGS ignore_data_skipping_indices='x_idx'; -- 正常。
SELECT * FROM data SETTINGS ignore_data_skipping_indices='na_idx'; -- 正常。

SELECT * FROM data WHERE x = 1 AND y = 1 SETTINGS ignore_data_skipping_indices='xy_idx',force_data_skipping_indices='xy_idx' ; -- xy_idxが明示的に無視されているため、クエリはINDEX_NOT_USEDエラーを返します。
SELECT * FROM data WHERE x = 1 AND y = 2 SETTINGS ignore_data_skipping_indices='xy_idx';

索引を一切無視しない場合のクエリ:

EXPLAIN indexes = 1 SELECT * FROM data WHERE x = 1 AND y = 2;

Expression ((Projection + Before ORDER BY))
  Filter (WHERE)
    ReadFromMergeTree (default.data)
    Indexes:
      PrimaryKey
        Condition: true
        Parts: 1/1
        Granules: 1/1
      Skip
        Name: x_idx
        Description: minmax GRANULARITY 1
        Parts: 0/1
        Granules: 0/1
      Skip
        Name: y_idx
        Description: minmax GRANULARITY 1
        Parts: 0/0
        Granules: 0/0
      Skip
        Name: xy_idx
        Description: minmax GRANULARITY 1
        Parts: 0/0
        Granules: 0/0

xy_idx 索引を無視する場合：

EXPLAIN indexes = 1 SELECT * FROM data WHERE x = 1 AND y = 2 SETTINGS ignore_data_skipping_indices='xy_idx';

Expression ((Projection + Before ORDER BY))
  Filter (WHERE)
    ReadFromMergeTree (default.data)
    Indexes:
      PrimaryKey
        Condition: true
        Parts: 1/1
        Granules: 1/1
      Skip
        Name: x_idx
        Description: minmax GRANULARITY 1
        Parts: 0/1
        Granules: 0/1
      Skip
        Name: y_idx
        Description: minmax GRANULARITY 1
        Parts: 0/0
        Granules: 0/0

MergeTree familyのテーブルで使用できます。

​

ignore_drop_queries_probability

有効にすると、サーバーは指定した確率で、すべての DROP table クエリを無視します (Memory および JOIN エンジンでは、DROP を TRUNCATE に置き換えます) 。テスト目的で使用されます

​

ignore_format_null_for_explain

有効な場合、EXPLAIN クエリでは FORMAT Null は無視され、代わりにデフォルトの出力フォーマットが使用されます。 無効な場合、FORMAT Null を指定した EXPLAIN クエリでは何も出力されません (後方互換性のある動作) 。

​

ignore_materialized_views_with_dropped_target_table

ビューへのプッシュ時には、削除されたターゲットテーブルを持つ MV を無視します

​

ignore_on_cluster_for_replicated_access_entities_queries

レプリケーションされたアクセスエンティティの管理クエリで、ON CLUSTER 句を無視します。

​

ignore_on_cluster_for_replicated_database

Replicated database に対する DDL クエリでは、常に ON CLUSTER 句を無視します。

​

ignore_on_cluster_for_replicated_named_collections_queries

レプリケートされた named collections に対する管理クエリでは、ON CLUSTER 句を無視します。

​

ignore_on_cluster_for_replicated_udf_queries

レプリケートされた UDF の管理クエリでは、ON CLUSTER 句を無視します。

​

implicit_select

先頭に SELECT キーワードを書かなくても単純な SELECT クエリを記述できるようにします。これにより、電卓のような使い方がしやすくなり、たとえば 1 + 2 を有効なクエリとして実行できます。

clickhouse-local ではデフォルトで有効になっており、明示的に無効化することもできます。

​

implicit_table_at_top_level

空でない場合、トップレベルで FROM を持たないクエリは、system.one ではなくこのテーブルから読み取ります。

これは、clickhouse-local で入力データを処理する際に使用されます。 この設定はユーザーが明示的に設定することもできますが、そのような用途は想定されていません。

サブクエリはこの設定の影響を受けません (スカラー、FROM、IN のいずれのサブクエリも対象外です) 。 UNION、INTERSECT、EXCEPT の連鎖におけるトップレベルの SELECT は、かっこによるグループ化にかかわらず一律に扱われ、この設定の影響を受けます。 この設定がビューや分散クエリにどのような影響を与えるかは規定されていません。

この設定には、テーブル名 (この場合、テーブルは現在のデータベースから解決されます) または ‘database.table’ 形式の修飾名を指定できます。 データベース名とテーブル名はどちらもクォートなしでなければならず、使用できるのは単純な識別子のみです。

​

implicit_transaction

有効で、かつまだトランザクション内でない場合、クエリを完全なトランザクション (begin + commit または rollback) で囲みます

​

inject_random_order_for_select_without_order_by

有効にすると、ORDER BY 句のない SELECT クエリに ‘ORDER BY rand()’ を挿入します。 適用されるのはサブクエリの深さ = 0 の場合のみです。サブクエリおよび INSERT INTO … SELECT には影響しません。 最上位の構文が UNION の場合、‘ORDER BY rand()’ は各子要素に個別に挿入されます。 テストや開発でのみ有用です (ORDER BY がないと、クエリ結果が非決定的になる原因となります) 。

​

insert_allow_materialized_columns

この設定を有効にすると、INSERT でマテリアライズドカラムを使用できます。

​

insert_deduplicate

INSERT のブロック重複排除 (Replicated* テーブル用) を有効または無効にします。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

デフォルトでは、INSERT ステートメントによってレプリケートテーブルに挿入されたブロックは重複排除されます (Data Replication を参照) 。 レプリケートテーブルでは、デフォルトで各パーティションにつき直近 100 個のブロックのみが重複排除されます (replicated_deduplication_window、replicated_deduplication_window_seconds を参照) 。 レプリケーションされないテーブルについては、non_replicated_deduplication_window を参照してください。

​

insert_deduplication_token

この設定を使用すると、MergeTree/ReplicatedMergeTree で独自の deduplication の動作を指定できます。 たとえば、各 INSERT ステートメントでこの設定に一意の値を指定することで、 同じデータが deduplication によって排除されるのを防げます。

設定可能な値:

• 任意の文字列

insert_deduplication_token は、空でない場合にのみ deduplication に使用されます。

レプリケートテーブルでは、デフォルトで各パーティションごとに直近 100 件の insert のみが deduplication の対象になります (replicated_deduplication_window、replicated_deduplication_window_seconds を参照) 。 非レプリケートテーブルについては、non_replicated_deduplication_window を参照してください。

insert_deduplication_token はパーティション単位で機能します (insert_deduplication checksum と同じです) 。複数のパーティションで同じ insert_deduplication_token を使用できます。

例:

CREATE TABLE test_table
( A Int64 )
ENGINE = MergeTree
ORDER BY A
SETTINGS non_replicated_deduplication_window = 100;

INSERT INTO test_table SETTINGS insert_deduplication_token = 'test' VALUES (1);

-- 次のinsertはinsert_deduplication_tokenが異なるため、重複排除されない
INSERT INTO test_table SETTINGS insert_deduplication_token = 'test1' VALUES (1);

-- 次のinsertはinsert_deduplication_tokenが
-- 以前のいずれかと同じであるため、重複排除される
INSERT INTO test_table SETTINGS insert_deduplication_token = 'test' VALUES (2);

SELECT * FROM test_table

┌─A─┐
│ 1 │
└───┘
┌─A─┐
│ 1 │
└───┘

​

insert_keeper_fault_injection_probability

insert 時の Keeper リクエストのおおよその失敗確率です。有効な値の範囲は [0.0f, 1.0f] です

​

insert_keeper_fault_injection_seed

0 の場合は乱数シード、それ以外の場合は設定値

​

insert_keeper_max_retries

この設定は、replicated MergeTree への insert 中に ClickHouse Keeper (または ZooKeeper) へのリクエストに対して実行する再試行の最大回数を設定します。再試行の対象となるのは、ネットワークエラー、Keeper セッションのタイムアウト、またはリクエストのタイムアウトによって失敗した Keeper リクエストのみです。

設定可能な値:

• 正の整数。
• 0 — 再試行は無効

Cloud でのデフォルト値: 20。

Keeper リクエストの再試行は、一定のタイムアウト後に実行されます。このタイムアウトは、次の設定で制御されます: insert_keeper_retry_initial_backoff_ms、insert_keeper_retry_max_backoff_ms。 最初の再試行は insert_keeper_retry_initial_backoff_ms のタイムアウト後に行われます。以降のタイムアウトは、次のように計算されます:

timeout = min(insert_keeper_retry_max_backoff_ms, latest_timeout * 2)

たとえば、insert_keeper_retry_initial_backoff_ms=100、insert_keeper_retry_max_backoff_ms=10000、insert_keeper_max_retries=8 の場合、タイムアウトは 100, 200, 400, 800, 1600, 3200, 6400, 10000 となります。

耐障害性に加え、これらの再試行にはユーザー体験を向上させる目的もあります。たとえば、アップグレードなどの理由で Keeper が再起動した場合でも、INSERT 実行中にエラーを返さずに済みます。

​

insert_keeper_retry_initial_backoff_ms

INSERT クエリの実行中に失敗した Keeper リクエストを再試行する際の初期タイムアウト (ミリ秒)

設定可能な値:

• 正の整数。
• 0 — タイムアウトなし

​

insert_keeper_retry_max_backoff_ms

INSERT クエリの実行中に失敗した Keeper リクエストを再試行する際の最大タイムアウト (ミリ秒)

設定可能な値:

• 正の整数。
• 0 — 最大タイムアウトは無制限

​

insert_null_as_default

Nullable ではないデータ型のカラムに対して、NULL の代わりに デフォルト値 を挿入するかどうかを有効または無効にします。 カラムの型が Nullable ではなく、この設定が無効な場合、NULL を挿入すると例外が発生します。カラムの型が Nullable の場合は、この設定に関係なく、NULL 値はそのまま挿入されます。

この設定は、INSERT … SELECT クエリに適用されます。SELECT サブクエリは UNION ALL 句で連結できる点に注意してください。

設定可能な値:

• 0 — Nullable ではないカラムに NULL を挿入すると例外が発生します。
• 1 — NULL の代わりにカラムのデフォルト値が挿入されます。

​

insert_quorum

この設定は SharedMergeTree には適用されません。詳細は SharedMergeTree consistency を参照してください。

クォーラム書き込みを有効にします。

• insert_quorum < 2 の場合、クォーラム書き込みは無効です。
• insert_quorum >= 2 の場合、クォーラム書き込みは有効です。
• insert_quorum = 'auto' の場合、クォーラム数には過半数 (number_of_replicas / 2 + 1) が使用されます。

クォーラム書き込み

INSERT は、ClickHouse が insert_quorum_timeout の間に insert_quorum 個のレプリカへのデータ書き込みを正常に完了できた場合にのみ成功します。何らかの理由で書き込みに成功したレプリカ数が insert_quorum に達しない場合、その書き込みは失敗とみなされ、ClickHouse はすでにデータが書き込まれているすべてのレプリカから挿入されたブロックを削除します。

insert_quorum_parallel が無効な場合、クォーラム内のすべてのレプリカは整合した状態になります。つまり、以前のすべての INSERT クエリによるデータが含まれます (INSERT の順序は線形化されます) 。insert_quorum を使って書き込まれたデータを読み取る際、insert_quorum_parallel が無効であれば、select_sequential_consistency を使用して SELECT クエリで逐次整合性を有効にできます。

ClickHouse は次の場合に例外を生成します。

• クエリ実行時点で利用可能なレプリカ数が insert_quorum 未満の場合。
• insert_quorum_parallel が無効で、前のブロックがまだ insert_quorum 個のレプリカに挿入されていない状態でデータを書き込もうとした場合。この状況は、ユーザーが insert_quorum を指定した前回の INSERT が完了する前に、同じテーブルに対して別の INSERT クエリを実行しようとすると発生する可能性があります。

関連項目:

• insert_quorum_timeout
• insert_quorum_parallel
• select_sequential_consistency

​

insert_quorum_parallel

この設定は SharedMergeTree には適用されません。詳細については SharedMergeTree consistency を参照してください。

クォーラム INSERT クエリの並列度を有効または無効にします。有効な場合、前のクエリがまだ完了していなくても追加の INSERT クエリを送信できます。無効な場合、同じテーブルへの追加の書き込みは拒否されます。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

関連項目:

• insert_quorum
• insert_quorum_timeout
• select_sequential_consistency

​

insert_quorum_timeout

クォーラムへの書き込みのタイムアウトをミリ秒単位で指定します。タイムアウトまでに書き込みが行われなかった場合、ClickHouse は例外を返し、クライアントは同じブロックを同じレプリカまたは他の任意のレプリカに書き込むために、同じクエリを再実行する必要があります。

関連項目:

• insert_quorum
• insert_quorum_parallel
• select_sequential_consistency

​

insert_shard_id

0 以外の場合、データを同期的に挿入する Distributed テーブルの分片を指定します。

insert_shard_id の値が正しくない場合、サーバーは例外をスローします。

requested_cluster の分片数を取得するには、サーバーの設定を確認するか、次のクエリを使用します。

SELECT uniq(shard_num) FROM system.clusters WHERE cluster = 'requested_cluster';

設定可能な値:

• 0 — 無効。
• 対応する Distributed テーブルの 1 から shards_num までの任意の数値。

例

クエリ:

CREATE TABLE x AS system.numbers ENGINE = MergeTree ORDER BY number;
CREATE TABLE x_dist AS x ENGINE = Distributed('test_cluster_two_shards_localhost', currentDatabase(), x);
INSERT INTO x_dist SELECT * FROM numbers(5) SETTINGS insert_shard_id = 1;
SELECT * FROM x_dist ORDER BY number ASC;

結果:

┌─number─┐
│      0 │
│      0 │
│      1 │
│      1 │
│      2 │
│      2 │
│      3 │
│      3 │
│      4 │
│      4 │
└────────┘

​

interactive_delay

リクエストの実行がキャンセルされたかどうかを確認し、進行状況を送信する間隔をマイクロ秒単位で指定します。

​

intersect_default_mode

INTERSECT クエリのデフォルトモードを設定します。設定可能な値: 空文字列、‘ALL’、‘DISTINCT’。空文字列の場合、モードを指定しないクエリでは例外がスローされます。

​

jemalloc_collect_profile_samples_in_trace_log

jemalloc の割り当ておよび解放のサンプルをトレースログに記録します。

​

jemalloc_enable_profiler

このクエリに対して jemalloc プロファイラを有効にします。Jemalloc は割り当てをサンプリングし、サンプリングされた割り当てに対するすべての解放も記録します。 プロファイルは SYSTEM JEMALLOC FLUSH PROFILE を使用してフラッシュでき、割り当ての分析に利用できます。 サンプルは、config の jemalloc_collect_global_profile_samples_in_trace_log またはクエリ設定の jemalloc_collect_profile_samples_in_trace_log を使用して system.trace_log に保存することもできます。 割り当てプロファイリング を参照してください

​

jemalloc_profile_text_collapsed_use_count

jemalloc ヒーププロファイルで collapsed 出力フォーマットを使用する場合、バイト数ではなく割り当て回数で集計します。false (デフォルト) の場合、各スタックは使用中のバイト数で重み付けされます。true の場合は、使用中の割り当て数で重み付けされます。

​

jemalloc_profile_text_output_format

system.jemalloc_profile_text テーブル内の jemalloc ヒーププロファイルの出力フォーマットです。指定できる値は、‘raw’ (生のプロファイル) 、‘symbolized’ (シンボル化された jeprof フォーマット) 、‘collapsed’ (フレームグラフ形式) です。

​

jemalloc_profile_text_symbolize_with_inline

jemallocヒーププロファイルのシンボル化時に、インラインフレームを含めるかどうかを指定します。有効にするとインラインフレームが含まれるため、シンボル化処理が大幅に遅くなる可能性があります。無効にするとスキップされます。影響があるのは、‘symbolized’ および ‘collapsed’ 出力フォーマットのみです。

​

join_algorithm

使用する JOIN アルゴリズムを指定します。

複数のアルゴリズムを指定でき、kind/strictness とテーブルエンジンに応じて、そのクエリで利用可能なものが選択されます。

設定可能な値:

• grace_hash

Grace hash join を使用します。Grace hash は、メモリ使用量を抑えながら複雑な join を高性能に実行できるアルゴリズムです。

Grace join の最初のフェーズでは、右側のテーブルを読み取り、キーカラムの hash value に応じて N 個のバケットに分割します (初期値の N は grace_hash_join_initial_buckets です) 。これは、各バケットを独立して処理できるようにするためです。最初のバケットの行はインメモリの hash table に追加され、それ以外はディスクに保存されます。hash table がメモリ制限 (たとえば max_bytes_in_join で設定) を超えるまで大きくなると、バケット数が増やされ、各行の割り当て先バケットが変更されます。現在のバケットに属さない行はフラッシュされ、再割り当てされます。

INNER/LEFT/RIGHT/FULL ALL/ANY JOIN をサポートします。

• hash

Hash join algorithm を使用します。これは最も汎用的な実装で、kind と strictness のすべての組み合わせ、および JOIN ON セクションで OR と組み合わせた複数の結合キーをサポートします。

hash アルゴリズムを使用する場合、JOIN の右側は RAM に読み込まれます。

• parallel_hash

hash join の一種で、データをバケットに分割し、1 つではなく複数のハッシュテーブルを同時実行で構築することで、この処理を高速化します。

parallel_hash アルゴリズムを使用する場合、JOIN の右側は RAM に読み込まれます。

• partial_merge

右側のテーブルだけを完全にソートする sort-merge algorithm の一種です。

RIGHT JOIN と FULL JOIN は ALL strictness でのみサポートされます (SEMI、ANTI、ANY、ASOF はサポートされません) 。

partial_merge アルゴリズムを使用する場合、ClickHouse はデータをソートしてディスクに書き出します。ClickHouse の partial_merge アルゴリズムは、従来の実装とは少し異なります。まず、ClickHouse は右側のテーブルを結合キーで block 単位にソートし、ソート済みの block に対して min-max 索引 を作成します。次に、左側のテーブルの一部を join key でソートして、右側のテーブルと結合します。不要な右側テーブルの block をスキップするために、min-max 索引 も使用されます。

• direct

direct (nested loop とも呼ばれます) アルゴリズムは、左側のテーブルの行をキーとして使用し、右側のテーブルに対してルックアップを行います。 Dictionary、EmbeddedRocksDB、MergeTree テーブルなどの特別なストレージでサポートされています。

MergeTree テーブルでは、このアルゴリズムは結合キーのフィルターをストレージ層に直接プッシュダウンします。キーのルックアップにテーブルの主キー索引を使える場合はより効率的ですが、そうでない場合は左側テーブルの各 block ごとに右側テーブルをフルスキャンします。

INNER と LEFT JOIN のみをサポートし、他の条件を含まない単一カラムの等価結合キーにのみ対応します。

• auto

auto に設定すると、まず hash join を試し、メモリ制限を超えた場合は実行中に別のアルゴリズムへ切り替えます。

• full_sorting_merge

結合前に対象のテーブルを完全にソートする sort-merge algorithm です。

• prefer_partial_merge

ClickHouse は可能であれば常に partial_merge join を使用し、そうでない場合は hash を使用します。非推奨 で、partial_merge,hash と同じです。

• default (deprecated)

古い値のため、今後は使用しないでください。 direct,hash と同じです。つまり、direct join と hash join をこの順に試します。

​

join_any_take_last_row

ANY strictness を持つ JOIN 演算の動作を変更します。

この設定は、Join エンジンのテーブルを使用する JOIN 演算にのみ適用されます。

設定可能な値:

• 0 — 右側テーブルに一致する行が複数ある場合、見つかった最初の 1 行のみが結合に使用されます。
• 1 — 右側テーブルに一致する行が複数ある場合、見つかった最後の 1 行のみが結合に使用されます。

関連項目:

• JOIN 句
• Join テーブルエンジン
• join_default_strictness

​

join_default_strictness

JOIN 句 のデフォルトの strictness を設定します。

設定可能な値:

• ALL — 右側のテーブルに一致する行が複数ある場合、ClickHouse は一致した行から 直積 を作成します。これは標準 SQL における通常の JOIN の動作です。
• ANY — 右側のテーブルに一致する行が複数ある場合、最初に見つかった 1 行だけが結合されます。右側のテーブルに一致する行が 1 行しかない場合、ANY と ALL の結果は同じです。
• ASOF — 対応が不確かな数列を結合するために使用します。
• 空文字列 — クエリで ALL または ANY が指定されていない場合、ClickHouse は例外をスローします。

​

join_on_disk_max_files_to_merge

ディスク上で実行される MergeJoin 演算で、並列ソートに使用できるファイル数の上限を設定します。

この設定値が大きいほど、使用する RAM は増え、必要なディスク I/O は減ります。

設定可能な値:

• 2 以上の任意の正の整数。

​

join_output_by_rowlist_perkey_rows_threshold

ハッシュ結合で行リストとして出力するかどうかを判断するための、右側テーブルにおけるキーごとの平均行数の下限。

​

join_overflow_mode

join が以下のいずれかの制限に達した際に、ClickHouse が実行する動作を定義します。

• max_bytes_in_join
• max_rows_in_join

この設定が適用されるのは、join_algorithm の値が hash または parallel_hash の場合のみです。その他のアルゴリズム (たとえば partial_merge、grace_hash、auto) では、これらの制限は別の方法で処理されます。たとえば、ディスクへのスピル、再パーティション化、または戦略の切り替えです。詳細は join_algorithm を参照してください。

設定可能な値:

• THROW — ClickHouse は例外をスローしてクエリを停止します。
• BREAK — ClickHouse はクエリを停止し、例外はスローしません。

デフォルト値: THROW。

関連項目

• JOIN 句
• Join テーブルエンジン

​

join_runtime_bloom_filter_bytes

JOIN ランタイムフィルタとして使用されるブルームフィルタのサイズ (バイト単位) です (enable_join_runtime_filters 設定を参照) 。

​

join_runtime_bloom_filter_hash_functions

JOIN のランタイムフィルタとして使用される bloom filter のハッシュ関数の数です (enable_join_runtime_filters 設定を参照) 。

​

join_runtime_bloom_filter_max_ratio_of_set_bits

ランタイム bloom filter の set bits の数がこの比率を超えると、オーバーヘッドを抑えるため、その filter は完全に無効化されます。

​

join_runtime_filter_blocks_to_skip_before_reenabling

以前、フィルタリング効率が低いために無効化されたランタイムフィルタを、動的に再度有効化してみるまでにスキップするブロック数。

​

join_runtime_filter_exact_values_limit

ランタイムフィルタ内でそのまま Set に格納される要素の最大数です。このしきい値を超えると、bloom filter に切り替わります。

​

join_runtime_filter_from_fixed_hash_table

ハッシュ結合のビルド側が FixedHashMap に変換された場合 (enable_join_fixed_hash_table_conversion を参照)、そのハッシュマップをランタイムフィルタとして直接利用します。

​

join_runtime_filter_pass_ratio_threshold_for_disabling

チェックした行に対する通過行の比率がこのしきい値を上回る場合、ランタイムフィルタは効果が低いと見なされ、オーバーヘッドを減らすため、次の join_runtime_filter_blocks_to_skip_before_reenabling ブロックの間は無効化されます。

​

join_to_sort_maximum_table_rows

LEFT JOIN または INNER JOIN で、右テーブルをキーで再配置するかどうかを判断するための、右テーブルの最大行数。

​

join_to_sort_minimum_perkey_rows

LEFT JOIN または INNER JOIN において、右テーブルをキーで再配置するかどうかを判断するための、右テーブルのキーごとの平均行数の下限です。この設定により、スパースなテーブルキーには最適化が適用されないようにします

​

join_use_nulls

JOIN の動作を設定します。テーブルをマージすると、空のセルが生じることがあります。ClickHouse はこの設定に応じて、それらを異なる方法で補完します。

設定可能な値:

• 0 — 空のセルは、対応するフィールド型のデフォルト値で補完されます。
• 1 — JOIN は標準 SQL と同じように動作します。対応するフィールドの型は Nullable に変換され、空のセルは NULL で補完されます。

​

joined_block_split_single_row

左テーブルの単一の行に対応する行単位で、ハッシュ結合の結果をchunkに分割できるようにします。 これにより、右テーブルで一致する行が多い行がある場合のメモリ使用量を削減できることがありますが、CPU使用量は増える可能性があります。 この設定を有効にするには、max_joined_block_size_rows != 0 が必須であることに注意してください。 この設定を max_joined_block_size_bytes と組み合わせると、右テーブルで一致する行が多い大きな行が一部にある偏ったデータにおいて、過剰なメモリ使用量を避けるのに役立ちます。

​

joined_subquery_requires_alias

名前修飾を正しく行えるように、結合に使用するサブクエリとテーブル関数に別名を必須とします。

​

kafka_disable_num_consumers_limit

使用可能な CPU コア数に応じて適用される kafka_num_consumers の制限を無効にします。

​

kafka_max_wait_ms

再試行する前に、Kafka からメッセージを読み取る際の待機時間 (ミリ秒) です。

設定可能な値:

• 正の整数。
• 0 — 無制限のタイムアウト。

関連項目:

• Apache Kafka

​

keeper_map_strict_mode

KeeperMap に対する操作時に追加のチェックを有効にします。たとえば、すでに存在するキーに insert した場合に例外をスローします

​

keeper_max_retries

一般的な Keeper 操作に対する最大再試行回数

​

keeper_retry_initial_backoff_ms

一般的なKeeper操作に対する初期バックオフタイムアウト

​

keeper_retry_max_backoff_ms

Keeper の一般的な操作に対する最大バックオフタイムアウト

​

least_greatest_legacy_null_behavior

有効にすると、関数 ‘least’ と ‘greatest’ は、いずれかの引数がNULLの場合にNULLを返します。

​

legacy_column_name_of_tuple_literal

大きなタプルリテラルでは、ハッシュではなく、各要素名を対応するカラム名としてすべて使用します。この設定は互換性のためにのみ存在します。21.7 未満のバージョンからそれ以降のバージョンへクラスターをローリングアップデートする際は、‘true’ に設定することを推奨します。

​

lightweight_delete_mode

論理削除の一部として実行される内部更新クエリのモードです。

設定可能な値:

• alter_update - ヘビーウェイトな mutation を作成する ALTER UPDATE クエリを実行します。
• lightweight_update - 可能であれば論理更新を実行し、そうでなければ ALTER UPDATE を実行します。
• lightweight_update_force - 可能であれば論理更新を実行し、そうでなければ例外を発生させます。

​

lightweight_deletes_sync

mutations_sync と同じですが、論理削除の実行のみを制御します。

設定可能な値:

値	説明
0	ミューテーションは非同期で実行されます。
1	クエリは、現在のサーバー上で論理削除が完了するまで待機します。
2	クエリは、すべてのレプリカ (存在する場合) で論理削除が完了するまで待機します。
3	クエリはアクティブなレプリカでの完了のみを待機します。SharedMergeTree でのみサポートされます。ReplicatedMergeTree では、mutations_sync = 2 と同じように動作します。

関連項目

• ALTER クエリの同期性
• Mutations

Cloud でのデフォルト値: 1.

​

limit

クエリ結果から取得する行数の上限を設定します。この設定は LIMIT 句で指定した値を調整し、クエリで指定した制限がこの設定で定めた上限を超えないようにします。

設定可能な値:

• 0 — 行数は制限されません。
• 正の整数。

​

load_balancing

分散クエリ処理で使用されるレプリカ選択アルゴリズムを指定します。

ClickHouse は、レプリカを選択するための次のアルゴリズムをサポートしています。

• ランダム (既定)
• 最も近いホスト名
• ホスト名のレーベンシュタイン距離
• ホスト名の最長共通プレフィックス
• ホスト名の最長共通接尾辞
• 定義順
• 最初またはランダム
• ラウンドロビン

関連項目:

• distributed_replica_max_ignored_errors

​

ランダム (デフォルト)

load_balancing = random

各レプリカについて、エラー数がカウントされます。クエリはエラーが最も少ないレプリカに送信され、そのようなレプリカが複数ある場合は、そのうちのいずれか 1 つに送られます。 欠点: サーバーへの近さは考慮されません。また、レプリカごとにデータが異なる場合は、取得されるデータも異なります。

​

Nearest hostname

load_balancing = nearest_hostname

各レプリカについて、エラー数がカウントされます。5 分ごとに、エラー数は整数除算で 2 で割られます。したがって、エラー数は指数平滑化により直近の時間に対して計算されます。エラー数が最小のレプリカが 1 つある場合 (つまり、他のレプリカでは最近エラーが発生していた場合) 、そのレプリカにクエリが送信されます。エラー数が同じ最小値のレプリカが複数ある場合は、設定ファイル内のサーバーのホスト名に最も近いホスト名を持つレプリカにクエリが送信されます (両方のホスト名のうち短い方の長さまで、同じ位置にある異なる文字数に基づきます) 。

たとえば、example01-01-1 と example01-01-2 は 1 文字だけ異なりますが、example01-01-1 と example01-02-2 は 2 か所で異なります。 この手法は一見すると素朴に思えるかもしれませんが、ネットワークトポロジーに関する外部データを必要とせず、また IP アドレスも比較しません。これは、IPv6 アドレスでは複雑になるためです。

したがって、同等のレプリカがある場合は、名前が最も近いものが優先されます。 また、同じサーバーにクエリを送信する場合、障害がなければ、分散クエリも同じサーバー群に送られると考えられます。したがって、レプリカに異なるデータが配置されていたとしても、そのクエリはほぼ同じ結果を返します。

​

ホスト名のレーベンシュタイン距離

load_balancing = hostname_levenshtein_distance

nearest_hostname と同様ですが、レーベンシュタイン距離 に基づいてホスト名を比較します。たとえば:

example-clickhouse-0-0 ample-clickhouse-0-0
1

example-clickhouse-0-0 example-clickhouse-1-10
2

example-clickhouse-0-0 example-clickhouse-12-0
3

​

ホスト名の最長共通プレフィックス

load_balancing = hostname_longest_common_prefix

nearest_hostname と同様ですが、ローカルの hostname と最長の共通プレフィックスを持つ hostname のレプリカが優先されます (共通プレフィックスが長いほど優先度が高くなります) 。文字ごとの差異を位置ごとに数える nearest_hostname とは異なり、この戦略は、数値セグメントの長さが異なる hostname があっても誤判定しません。たとえば、ローカルの hostname が sfe301 の場合:

sfe301 sde301
1

sfe301 sfe10101
3

sfe301 sde505
1

ここでは、sfe10101 は sfe301 と最も長い共通プレフィックス (sfe、長さ 3) を持つため、優先されます。

共通プレフィックスの長さが同じレプリカは、ランダムに選択されます。特に、ローカルの hostname とプレフィックスを共有するレプリカが 1 つもない場合 (すべての共通プレフィックス長が 0 の場合) 、この戦略の動作は random とまったく同じです。

​

ホスト名の最長共通接尾辞

load_balancing = hostname_longest_common_suffix

hostname_longest_common_prefix と同様ですが、プレフィックスではなく、最長の共通 接尾辞 を比較します。これは、データセンターの識別情報が hostname の接尾辞としてエンコードされている場合に便利です。たとえば、ローカル hostname が et46gtghn.qc.localdomain の場合:

et46gtghn.qc.localdomain tr676ddgh.td.localdomain
12

et46gtghn.qc.localdomain ab999.qc.localdomain
15

ここでは、ab999.qc.localdomain は et46gtghn.qc.localdomain と最も長い共通接尾辞 (.qc.localdomain、長さ 15) を持つため、優先されます。

共通接尾辞の長さが同じレプリカは、ランダムに選択されます。特に、ローカル hostname と接尾辞を共有するレプリカが 1 つもない場合 (すべての共通接尾辞の長さが 0 の場合) 、この戦略は random とまったく同じように動作します。

​

In Order

load_balancing = in_order

同じ数のエラーを持つレプリカには、設定で指定された順序どおりにアクセスされます。 この方法は、どのレプリカを優先すべきかを正確に把握している場合に適しています。

​

First or Random

load_balancing = first_or_random

このアルゴリズムは、対象のセット内で最初のレプリカを選択し、そのレプリカが利用できない場合はランダムなレプリカを選択します。これはクロスレプリケーショントポロジーのセットアップでは有効ですが、その他の構成ではほとんど意味がありません。

first_or_random アルゴリズムは、in_order アルゴリズムの問題を解決します。in_order では、1 つのレプリカがダウンすると、次のレプリカに負荷が 2 倍かかる一方で、残りのレプリカは通常どおりのトラフィック量を処理します。first_or_random アルゴリズムを使用すると、利用可能なレプリカ間で負荷が均等に分散されます。

設定 load_balancing_first_offset を使用すると、どのレプリカを最初のレプリカとするかを明示的に指定できます。これにより、レプリカ間でクエリのワークロードを再分散する際の制御性が高まります。

​

ラウンドロビン

load_balancing = round_robin

このアルゴリズムでは、エラー数が同じレプリカ間でラウンドロビン方式を使用します (カウント対象となるのは、round_robin ポリシーのクエリのみです) 。

​

load_balancing_first_offset

FIRST_OR_RANDOM ロードバランシング戦略を使用する際に、優先的にクエリを送信するレプリカを指定します。

​

load_marks_asynchronously

MergeTree のマークを非同期で読み込む

Cloud でのデフォルト値: 1.

​

local_filesystem_read_method

ローカルファイルシステムからデータを読み取る方法です。指定できる値は次のいずれかです: read, pread, mmap, io_uring, pread_threadpool。

‘io_uring’ メソッドは実験的な機能であり、読み取りと書き込みが同時実行される状況では、Log、TinyLog、StripeLog、File、Set、Join、および追記可能なファイルを持つその他のテーブルでは動作しません。 インターネット上の ‘io_uring’ に関するさまざまな記事を読んでも、それに惑わされないでください。大量の小さな I/O リクエストがある場合を除き、これはより優れたファイル読み取り方法ではありません。ClickHouse ではそのようなケースには当てはまりません。‘io_uring’ を有効にする理由はありません。

​

local_filesystem_read_prefetch

ローカルファイルシステムからデータを読み込む際に先読みを使用するかどうかを指定します。

​

lock_acquire_timeout

ロック要求が失敗するまでに待機する秒数を定義します。

ロックのタイムアウトは、テーブルに対する読み取り/書き込み操作の実行中にデッドロックを防ぐために使用されます。タイムアウトに達してロック要求が失敗すると、ClickHouse server はエラーコード DEADLOCK_AVOIDED とともに、例外 “Locking attempt timed out! Possible deadlock avoided. Client should retry.” をスローします。

設定可能な値:

• 正の整数 (秒単位) 。
• 0 — ロックのタイムアウトなし。

​

log_comment

system.query_log テーブルの log_comment フィールドの値と、サーバーログに出力するコメントテキストを指定します。

サーバーログの可読性を高めるために使用できます。さらに、clickhouse-test の実行後に、system.query_log からテストに関連するクエリを抽出する際にも役立ちます。

設定可能な値:

• max_query_size 以下の任意の文字列。max_query_size を超えると、サーバーは例外を発生させます。

例

クエリ:

SET log_comment = 'log_comment test', log_queries = 1;
SELECT 1;
SYSTEM FLUSH LOGS;
SELECT type, query FROM system.query_log WHERE log_comment = 'log_comment test' AND event_date >= yesterday() ORDER BY event_time DESC LIMIT 2;

結果:

┌─type────────┬─query─────┐
│ QueryStart  │ SELECT 1; │
│ QueryFinish │ SELECT 1; │
└─────────────┴───────────┘

​

log_formatted_queries

整形済みのクエリを system.query_log システムテーブルに記録します (system.query_log の formatted_query カラムに格納されます) 。

設定可能な値:

• 0 — 整形済みのクエリはシステムテーブルに記録されません。
• 1 — 整形済みのクエリはシステムテーブルに記録されます。

​

log_processors_profiles

実行中またはデータ待機中にプロセッサが費やした時間を、system.processors_profile_log テーブルに書き込みます。

関連項目:

• system.processors_profile_log
• EXPLAIN PIPELINE

​

log_profile_events

クエリパフォーマンスに関する統計を、query_log、query_thread_log、query_views_log に記録します。

​

log_queries

クエリのログ記録を設定します。

この設定を有効にすると、ClickHouse に送信されたクエリは、サーバー設定パラメーター query_log のルールに従って記録されます。

例:

log_queries=1

​

log_queries_cut_to_length

クエリの長さが指定したしきい値 (バイト単位) を超える場合、クエリログに書き込む際にクエリを切り詰めます。通常のテキストログに出力されるクエリの長さも制限します。

​

log_queries_min_query_duration_ms

有効な場合 (0 以外) 、この設定値より短時間で完了するクエリはログに記録されません (これは MySQL Slow Query Log の long_query_time に相当すると考えられます) 。つまり、これらのクエリは次のテーブルには記録されません。

• system.query_log
• system.query_thread_log

ログに記録されるのは、次の種類のクエリだけです。

• QUERY_FINISH

• EXCEPTION_WHILE_PROCESSING

• 型: ミリ秒

• デフォルト値: 0 (すべてのクエリ)

​

log_queries_min_type

記録する query_log の最小種別です。

設定可能な値:

• QUERY_START (=1)
• QUERY_FINISH (=2)
• EXCEPTION_BEFORE_START (=3)
• EXCEPTION_WHILE_PROCESSING (=4)

query_log に記録される項目を制限するために使用できます。たとえば、エラーのみに関心がある場合は、EXCEPTION_WHILE_PROCESSING を使用できます:

log_queries_min_type='EXCEPTION_WHILE_PROCESSING'

​

log_queries_probability

指定した確率でランダムに選択されたクエリのサンプルのみを、query_log、query_thread_log、およびquery_views_log システムテーブルに書き込みます。これにより、1 秒あたりのクエリ数が多い場合の負荷を軽減できます。

設定可能な値:

• 0 — クエリはシステムテーブルに記録されません。
• [0..1] の範囲の正の浮動小数点数。たとえば、設定値が 0.5 の場合、クエリのおよそ半分がシステムテーブルに記録されます。
• 1 — すべてのクエリがシステムテーブルに記録されます。

​

log_query_settings

クエリ設定を query_log および OpenTelemetry の span ログに記録します。

​

log_query_threads

クエリスレッドのログ記録を設定します。

クエリスレッドは system.query_thread_log テーブルに記録されます。この設定は、log_queries が true の場合にのみ有効です。この設定を有効にすると、ClickHouse が実行するクエリのスレッドは、query_thread_log サーバー設定パラメータのルールに従って記録されます。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

例

log_query_threads=1

​

log_query_views

クエリビューのログ記録を設定します。

この設定を有効にすると、ClickHouse が実行したクエリに関連するビュー (マテリアライズドビューまたは live view) がある場合、それらはサーバー設定パラメータ query_views_log に記録されます。

例:

log_query_views=1

​

low_cardinality_allow_in_native_format

Nativeフォーマットで LowCardinality データ型の使用を許可または制限します。

LowCardinality の使用が制限されている場合、ClickHouseサーバーは SELECT クエリでは LowCardinality カラムを通常のカラムに変換し、INSERT クエリでは通常のカラムを LowCardinality カラムに変換します。

この設定は主に、LowCardinality データ型をサポートしていないサードパーティ製クライアント向けに必要です。

設定可能な値:

• 1 — LowCardinality の使用は制限されません。
• 0 — LowCardinality の使用は制限されます。

​

low_cardinality_max_dictionary_size

ストレージのファイルシステムに書き込める、LowCardinality データ型の共有グローバル Dictionary の最大サイズを行数で設定します。この設定により、Dictionary が無制限に増大した場合の RAM に関する問題を防ぎます。Dictionary の最大サイズ制限のためにエンコードできないデータは、ClickHouse によって通常の方法で書き込まれます。

設定可能な値:

• 任意の正の整数。

​

low_cardinality_use_single_dictionary_for_part

data part に対して単一の Dictionary を使用するかどうかを切り替えます。

デフォルトでは、ClickHouseサーバーは Dictionary のサイズを監視しており、Dictionary がオーバーフローすると次の Dictionary への書き込みを開始します。複数の Dictionary が作成されないようにするには、low_cardinality_use_single_dictionary_for_part = 1 を設定します。

設定可能な値:

• 1 — data part に対して複数の Dictionary を作成することを禁止します。
• 0 — data part に対して複数の Dictionary を作成することを禁止しません。

​

low_priority_query_wait_time_ms

クエリの優先順位付けの仕組みが使用されている場合 (設定 priority を参照) 、低優先度のクエリは高優先度のクエリの完了を待機します。この設定では、その待機時間を指定します。

​

make_distributed_plan

分散クエリプランを生成します。

​

materialize_skip_indexes_on_insert

INSERT 時にスキップ索引を構築して保存するかどうかを指定します。無効にすると、スキップ索引はマージ時または明示的なMATERIALIZE INDEXによってのみ構築・保存されます。

関連項目: exclude_materialize_skip_indexes_on_insert。

​

materialize_statistics_on_insert

INSERT で統計を作成して挿入するかどうかを指定します。無効にすると、統計はマージ時、または明示的な MATERIALIZE STATISTICS によって作成・保存されます

​

materialize_ttl_after_modify

ALTER MODIFY TTL クエリの実行後、古いデータに有効期限 (TTL) を適用します

​

materialized_views_ignore_errors

有効にすると、依存する materialized view へのデータのプッシュ中 (その SELECT 内、または内部テーブルのシンク内) に投げられた例外は警告としてログに記録され、INSERT ステートメントは成功します。無効 (デフォルト) の場合、そのような例外は伝播し、INSERT ステートメントは失敗します。

この設定が制御するのはエラー報告だけです。ソーステーブルへの書き込みはロールバックされず、依存ビューのパイプラインでエラーが発生した時点で、元の block がすでにソーステーブルに commit 済みかどうかも保証されません。無効 (デフォルト) の場合、ビューエラーによって INSERT は失敗します。ソーステーブルとすべての依存ビューに exactly-once 配信を実現するには、挿入の重複排除 (insert_deduplicate, deduplicate_blocks_in_dependent_materialized_views) を指定して再試行してください。有効にすると、失敗したビューとその下流の chain への配信が部分的であっても、INSERT は成功として報告されます。これは、ソーステーブルへの書き込みをビュー側の問題でブロックしてはならない場合 (たとえば system.*_log テーブル) にのみ使用してください。完全なセマンティクスについては、CREATE VIEW のドキュメントを参照してください。

​

materialized_views_squash_parallel_inserts

生成されるパーツ数を減らすため、単一の INSERT クエリによる materialized view の宛先テーブルへの並列 insert をまとめます。 false に設定され、かつ parallel_view_processing が有効な場合、INSERT クエリは max_insert_thread ごとに宛先テーブルにパーツを生成します。

​

max_analyze_depth

インタープリターが実行する解析の最大回数。

​

max_ast_depth

クエリの構文木の最大ネスト深度です。これを超えると、例外が発生します。

現時点では、これはパース中にはチェックされず、クエリのパース後にのみチェックされます。 つまり、パース中に深すぎる構文木が作成される可能性はありますが、 そのクエリは失敗します。

​

max_ast_elements

クエリ構文木内の要素数の上限です。これを超えると、例外が発生します。

現時点では、これはパース中にはチェックされず、クエリのパース完了後にのみチェックされます。 つまり、パース中に深さが大きすぎる構文木が生成される可能性はありますが、 そのクエリは失敗します。

​

max_autoincrement_series

generateSerialID 関数で作成されるシリーズ数の上限です。

各シリーズは Keeper 内のノードを表すため、その数は多くても数百万個程度に抑えることを推奨します。

​

max_backup_bandwidth

server 上の特定のバックアップにおける、1 秒あたりの最大読み取り速度 (バイト単位) です。0 は無制限を意味します。

​

max_block_size

ClickHouse では、データは block (カラムのパーツの集合) 単位で処理されます。単一の block に対する内部処理サイクル自体は効率的ですが、各 block の処理には無視できないコストがかかります。

max_block_size 設定は、テーブルからデータを読み込む際に、1 つの block に含める行数の推奨最大値を示します。ただし、常に max_block_size サイズの block がテーブルから読み込まれるわけではありません。ClickHouse が、取得するデータ量はそれより少なくてよいと判断した場合は、より小さい block が処理されます。

各 block の処理コストが目立たないようにするため、block サイズは小さすぎてはいけません。また、LIMIT 句を含むクエリが最初の block の処理後すぐに実行できるようにするため、大きすぎてもいけません。max_block_size を設定する際は、複数のスレッドで多数のカラムを抽出するときにメモリを過剰に消費しないこと、そして少なくともある程度の cache 局所性を保つことを目標にしてください。

​

max_bytes_before_external_group_by

Cloud でのデフォルト値: レプリカあたりのメモリ量の半分。

GROUP BY 句を外部メモリで実行する機能を有効または無効にします。 (外部メモリでの GROUP BY を参照)

設定可能な値:

• 1 回の GROUP BY 操作で使用できる RAM の最大量 (バイト単位) 。
• 0 — 外部メモリでの GROUP BY は無効です。

GROUP BY 操作中のメモリ使用量がこのしきい値 (バイト単位) を超えると、 「external aggregation」モードが有効になり、中間データがディスクに書き出されます。

推奨値は、使用可能なシステムメモリの半分です。

​

max_bytes_before_external_join

0以外の値に設定され、join_algorithm が hash、parallel_hash、default、または auto の場合、右側のデータがこのバイト数を超えると、ディスクへのスピルを可能にするため、ハッシュ結合は自動的に Grace Hash Join に変換されます。0 (デフォルト) に設定すると、この絶対バイトしきい値は無効になりますが、max_bytes_ratio_before_external_join (デフォルトは 0.5) により自動スピルが発生する可能性はあります。自動スピルを完全に無効にするには、両方を 0 に設定してください。これにより、JOIN 最適化による read in order は行われなくなります。

​

max_bytes_before_external_sort

Cloud でのデフォルト値: レプリカごとのメモリ量の半分。

ORDER BY 句を外部メモリで実行するかどうかを制御します。詳細は ORDER BY Implementation Details を参照してください。 ORDER BY の処理中にメモリ使用量がこのしきい値 (バイト単位) を超えると、「外部ソート」モード (データをディスクに書き出す) が有効になります。

設定可能な値:

• 1 回の ORDER BY 操作で使用できる RAM の最大量 (バイト単位) 。 推奨値は、利用可能なシステムメモリの半分です
• 0 — 外部メモリでの ORDER BY は無効です。

​

max_bytes_before_remerge_sort

ORDER BY と LIMIT を使用する場合、メモリ使用量が指定したしきい値を超えると、最終的なマージの前にブロックを追加でマージする処理を行い、上位 LIMIT 行だけを保持します。

​

max_bytes_for_lazy_final

lazy FINAL 最適化で使用するセットの最大バイト数です。これを超えると、通常の FINAL にフォールバックします。

​

max_bytes_in_distinct

DISTINCT 使用時にハッシュテーブルが使用する、メモリ内の状態の最大バイト数 (非圧縮バイト単位) 。

​

max_bytes_in_join

テーブルの join 時に使用される右側のデータ構造 (通常はハッシュ テーブル) の最大サイズ (バイト数) です。

この設定は、SELECT … JOIN 操作と Join table engine に適用されます。

クエリに複数の join が含まれている場合、ClickHouse は中間結果ごとにこの設定を確認します。上限に達した場合の動作は、選択した join_algorithm に依存します。アルゴリズムごとの動作 (スピル、再パーティション、切り替え、または join_overflow_mode に従った throw/break) については、その設定を参照してください。

設定可能な値:

• 正の整数。
• 0 — メモリ制御は無効です。

​

max_bytes_in_set

サブクエリから作成された IN 句内の Set が使用する最大バイト数 (非圧縮データ) 。

​

max_bytes_ratio_before_external_group_by

GROUP BY に使用できる、利用可能メモリの割合です。しきい値に達すると、 外部メモリを使用した集約に切り替わります。

たとえば 0.6 に設定すると、GROUP BY は実行開始時に利用可能メモリ (server/user/merges に対する) の 60% まで使用できます。それ以降は、 外部集約を使用し始めます。

​

max_bytes_ratio_before_external_join

JOIN に使用できる利用可能メモリの比率です。この値に達すると、ハッシュ結合は Grace Hash Join に変換され、右側のデータをディスクにスピルします。

たとえば 0.6 に設定すると、JOIN は実行開始時に、利用可能なメモリ (server/user/merges 用) の 60% を右側のハッシュテーブルに使用できます。それ以降はディスクへのスピルを開始します。

max_bytes_before_external_join と max_bytes_ratio_before_external_join の両方が設定されている場合は、しきい値として小さい方が使用されます。比率が 0 の場合は、絶対値の設定のみが適用されます。

join_algorithm が hash、parallel_hash、default、または auto であり、一時データのパスが設定されている場合にのみ有効です。

​

max_bytes_ratio_before_external_sort

ORDER BY に使用できる、利用可能メモリの割合です。この値に達すると、外部ソートが使用されます。

たとえば 0.6 に設定すると、ORDER BY は実行開始時に利用可能メモリ (server/user/merges に対する) の 60% まで使用できます。その後は外部ソートの使用を開始します。

なお、max_bytes_before_external_sort は引き続き適用されるため、ディスクへのスピルが行われるのは、ソートブロックが max_bytes_before_external_sort を超える場合のみです。

​

max_bytes_to_read

クエリの実行時に、tableから読み取れる最大バイト数 (非圧縮データ) です。 この制限は、処理されるデータの各chunkごとにチェックされ、最も深いtable expressionにのみ適用されます。リモートサーバーから読み取る場合は、リモートサーバー上でのみチェックされます。

​

max_bytes_to_read_leaf

分散クエリの実行時に、リーフノード上のローカル テーブルから読み取れる最大バイト数 (非圧縮データ) です。分散クエリでは、 各分片 (リーフ) に対して複数のサブクエリが発行される場合がありますが、この制限が チェックされるのはリーフノードでの読み取り段階のみであり、ルートノードでの 結果のマージ段階では無視されます。

たとえば、あるクラスターが 2 つの分片で構成され、各分片に 100 バイトのデータを持つテーブルが 含まれているとします。両方のテーブルからすべてのデータを読み取る 分散クエリで設定 max_bytes_to_read=150 を指定すると、合計で 200 バイトになるため失敗します。max_bytes_to_read_leaf=150 を指定したクエリは、 リーフノードが最大でも 100 バイトしか読み取らないため成功します。

この制限は、処理される各 chunk のデータに対してチェックされます。

この設定は prefer_localhost_replica=1 では安定しません。

​

max_bytes_to_sort

ソート前に処理できる最大バイト数。ORDER BY 操作で、指定した量を超える 非圧縮バイトを処理する必要がある場合の動作は、sort_overflow_mode によって 決まります。デフォルト値は throw です。

​

max_bytes_to_transfer

GLOBAL IN/JOIN セクションの実行時に、リモートサーバーに渡す、または一時テーブルに保存できる最大バイト数 (非圧縮データ) 。

​

max_columns_to_read

1 回のクエリで table から読み取れるカラムの最大数です。 クエリで指定した数を超えるカラムを読み取る必要がある場合は、例外 がスローされます。

この設定は、過度に複雑なクエリを防ぐのに役立ちます。

0 は無制限を意味します。

​

max_compress_block_size

テーブルへの書き込み時に圧縮する前の、非圧縮データのブロックの最大サイズです。デフォルト値は 1,048,576 (1 MiB) です。一般に、より小さいブロックサイズを指定すると圧縮率はわずかに低下しますが、cache の局所性により圧縮および展開の速度はわずかに向上し、メモリ消費量は減少します。

これは上級者向けの設定です。ClickHouse を使い始めたばかりであれば、変更しないでください。

圧縮用のブロック (バイトで構成されるメモリの chunk) と、クエリ処理用のブロック (テーブルの行の集合) を混同しないでください。

​

max_concurrent_queries_for_all_users

この設定の値が、現在同時に処理されているクエリ数以下の場合、例外をスローします。

例: max_concurrent_queries_for_all_users はすべてのユーザーに対して 99 に設定でき、データベース管理者は、server が過負荷状態でも調査用のクエリを実行できるよう、自身については 100 に設定できます。

1 つのクエリまたはユーザーに対してこの設定を変更しても、他のクエリには影響しません。

設定可能な値:

• 正の整数。
• 0 — 制限なし。

例

<max_concurrent_queries_for_all_users>99</max_concurrent_queries_for_all_users>

関連項目

• max_concurrent_queries

Cloud でのデフォルト値: 1000。

​

max_concurrent_queries_for_user

ユーザーごとに同時実行できるクエリの最大数です。

設定可能な値:

• 正の整数。
• 0 — 制限なし。

例

<max_concurrent_queries_for_user>5</max_concurrent_queries_for_user>

​

max_consume_snapshots

1 回のインクリメンタル読み取りで消費する Paimon スナップショットの最大数。0 は無制限を意味します。

​

max_distributed_connections

単一の分散テーブルに対する1つのクエリの分散処理において、リモートサーバーとの同時接続数の上限です。値は、クラスター内のサーバー数以上に設定することを推奨します。

以下のパラメータは、分散テーブルの作成時 (およびサーバーの起動時) にのみ使用されるため、実行時に変更する必要はありません。

​

max_distributed_depth

Distributed テーブルに対する再帰クエリの最大深さを制限します。

この値を超えると、サーバーで例外がスローされます。

設定可能な値:

• 正の整数。
• 0 — 深さは無制限。

​

max_download_buffer_size

各スレッドごとの並列ダウンロード用バッファ (例: URL engine) の最大サイズ。

​

max_download_threads

データをダウンロードするためのスレッドの最大数です (例: URL engine) 。

​

max_estimated_execution_time

秒単位で指定する、クエリの推定実行時間の上限です。各データブロックについて、 timeout_before_checking_execution_speed が経過するたびにチェックされます。

​

max_execution_speed

1 秒あたりの実行行数の上限です。各データブロックごとに、 timeout_before_checking_execution_speed が経過するとチェックされます。実行速度が高すぎる場合は、実行速度が抑制されます。

​

max_execution_speed_bytes

1 秒あたりの実行バイト数の上限です。各データブロックで timeout_before_checking_execution_speed の期限が切れるたびにチェックされます。実行速度が高すぎる場合は、実行速度が抑制されます。

​

max_execution_time

クエリの最大実行時間 (秒) です。

max_execution_time パラメータは、少し理解しにくい場合があります。 これは、現在のクエリ実行速度に対する補間に基づいて動作します (この動作は timeout_before_checking_execution_speed で制御されます) 。

ClickHouse は、予測される実行時間が指定された max_execution_time を超える場合、クエリを中断します。デフォルトでは、timeout_before_checking_execution_speed は 10 秒に設定されています。つまり、クエリの実行開始から 10 秒後に、ClickHouse は 合計実行時間の推定を開始します。たとえば、max_execution_time が 3600 秒 (1 時間) に設定されている場合、推定される実行時間がこの 3600 秒の上限を超えると、ClickHouse は クエリを終了します。timeout_before_checking_execution_speed を 0 に設定すると、ClickHouse は max_execution_time の基準として実際の経過時間を使用します。

クエリの実行時間が指定された秒数を超えた場合の動作は、 デフォルトで throw に設定されている timeout_overflow_mode によって決まります。

タイムアウトがチェックされ、クエリを停止できるのは、データ処理中の決められた箇所だけです。 現時点では、集約状態のマージ中やクエリ解析中には停止できないため、 実際の実行時間はこの設定値を上回ります。

​

max_execution_time_leaf

意味としては max_execution_time に似ていますが、分散クエリまたはリモートクエリのリーフノードにのみ 適用されます。

たとえば、初期ノードには制限を設けず、リーフノードでの実行時間だけを 10s に制限したい場合は、 ネストされたサブクエリの設定で max_execution_time を指定する代わりに、

SELECT count()
FROM cluster(cluster, view(SELECT * FROM t SETTINGS max_execution_time = 10));

クエリ設定には max_execution_time_leaf を使用できます。

SELECT count()
FROM cluster(cluster, view(SELECT * FROM t)) SETTINGS max_execution_time_leaf = 10;

​

max_expanded_ast_elements

別名とアスタリスクを展開した後の、ノード数で表したクエリ構文木の最大サイズ。

​

max_fetch_partition_retries_count

別のホストからパーティションを取得する際の再試行回数。

​

max_final_threads

FINAL 修飾子を使用する SELECT クエリのデータ読み取りフェーズで使用される、並列スレッドの最大数を設定します。

設定可能な値:

• 正の整数。
• 0 または 1 — 無効。SELECT クエリは単一スレッドで実行されます。

​

max_http_get_redirects

許可される HTTP GET リダイレクトの最大ホップ数です。悪意のあるサーバーによってリクエストが想定外のサービスへリダイレクトされるのを防ぐための、追加のセキュリティ対策になります。\n\nこれは、外部サーバーが別のアドレスへリダイレクトし、そのアドレスが会社のインフラストラクチャ内部にあるように見える場合に該当します。このとき内部サーバーに HTTP リクエストを送信すると、認証を回避して内部ネットワーク上の内部 API にリクエストしたり、Redis や Memcached などの他のサービスにクエリを送信したりできてしまう可能性があります。内部インフラストラクチャ (localhost で動作しているものを含む) が存在しない場合、またはそのサーバーを信頼している場合は、リダイレクトを許可しても安全です。ただし、URL が HTTPS ではなく HTTP を使用している場合は、リモートサーバーだけでなく、ISP や経路上のすべてのネットワークも信頼する必要がある点に注意してください。

Cloud でのデフォルト値: 10.

​

max_hyperscan_regexp_length

hyperscan multi-match functions における各正規表現の最大長を定義します。

設定可能な値:

• 正の整数。
• 0 - 長さは制限されません。

例

クエリ:

SELECT multiMatchAny('abcd', ['ab','bcd','c','d']) SETTINGS max_hyperscan_regexp_length = 3;

結果:

┌─multiMatchAny('abcd', ['ab', 'bcd', 'c', 'd'])─┐
│                                              1 │
└────────────────────────────────────────────────┘

クエリ:

SELECT multiMatchAny('abcd', ['ab','bcd','c','d']) SETTINGS max_hyperscan_regexp_length = 2;

結果:

Exception: Regexp length too large.

関連項目

• max_hyperscan_regexp_total_length

​

max_hyperscan_regexp_total_length

各 hyperscan multi-match function における、すべての正規表現の合計長の上限を設定します。

設定可能な値:

• 正の整数。
• 0 - 長さは制限されません。

例

クエリ:

SELECT multiMatchAny('abcd', ['a','b','c','d']) SETTINGS max_hyperscan_regexp_total_length = 5;

結果:

┌─multiMatchAny('abcd', ['a', 'b', 'c', 'd'])─┐
│                                           1 │
└─────────────────────────────────────────────┘

クエリ:

SELECT multiMatchAny('abcd', ['ab','bc','c','d']) SETTINGS max_hyperscan_regexp_total_length = 5;

結果:

Exception: Total regexp lengths too large.

関連項目

• max_hyperscan_regexp_length

​

max_insert_block_size

別名: max_insert_block_size_rows

テーブルに挿入するために形成されるブロックの最大サイズ (行数) です。

この設定は、次の 2 つの文脈でのブロック形成を制御します。

1. フォーマットのパース: サーバーが任意のインターフェイス (HTTP、インラインデータを伴う clickhouse-client、gRPC、PostgreSQL ワイヤプロトコル) から行ベースの入力フォーマット (CSV、TSV、JSONEachRow など) をパースする場合、ブロックは次の条件で生成されます:

   • min_insert_block_size_rows と min_insert_block_size_bytes の両方に達した場合、または
   • max_insert_block_size_rows または max_insert_block_size_bytes のいずれかに達した場合

   注: clickhouse-client または clickhouse-local を使用してファイルから読み取る場合、データのパースはクライアント自体が行うため、この設定はクライアント側に適用されます。

2. INSERT 操作: INSERT クエリの実行中、およびデータが materialized view を通過する際のこの設定の動作は、use_strict_insert_block_limits によって決まります:

   • 有効な場合: ブロックは次の条件で生成されます:

     • 最小しきい値 (AND): min_insert_block_size_rows と min_insert_block_size_bytes の両方に達した場合
     • 最大しきい値 (OR): max_insert_block_size_rows または max_insert_block_size_bytes のいずれかに達した場合

   • 無効な場合: ブロックは min_insert_block_size_rows または min_insert_block_size_bytes のいずれかに達した時点で生成されます。max_insert_block_size の設定は適用されません。

設定可能な値:

• 正の整数。

​

max_insert_block_size_bytes

テーブルに挿入するために形成されるブロックの最大サイズ (バイト単位) 。

この設定は max_insert_block_size_rows と組み合わせて動作し、同じコンテキストでブロック形成を制御します。これらの設定がいつ、どのように適用されるかの詳細については、max_insert_block_size_rows を参照してください。

設定可能な値:

• 正の整数。
• 0 — この設定はブロック形成に関与しません。

​

max_insert_delayed_streams_for_parallel_write

最終的な part のフラッシュを遅延させるストリーム (カラム) の最大数です。デフォルトは auto です (基盤となるストレージが並列書き込みをサポートしている場合は 100。たとえば S3。サポートしていない場合は無効です)

Cloud でのデフォルト値: 50.

​

max_insert_threads

INSERT SELECT クエリの実行に使用するスレッドの最大数です。

設定可能な値:

• 0 (または 1) — INSERT SELECT は並列実行されません。
• 正の整数。1 より大きい値。

Cloud でのデフォルト値:

• メモリ 8 GiB のノードでは 1
• メモリ 16 GiB のノードでは 2
• より大きなノードでは 4

並列 INSERT SELECT が有効になるのは、SELECT 部分も並列に実行される場合のみです。max_threads 設定を参照してください。 値を大きくすると、メモリ使用量も増加します。

​

max_insert_threads_min_free_memory_per_thread

max_threads ではなく max_insert_threads に適用される点を除き、max_threads_min_free_memory_per_thread と同じです。デフォルト値が高く設定されているのは、挿入パイプラインでは通常、読み取りパイプラインよりもスレッドごとに大きなバッファ (MergeTree パーツ、圧縮ブロック) を保持するためです。

空きメモリ量が max_insert_threads にこの値を掛けた値を下回る場合、max_insert_threads は収まるように最小 1 まで減らされます。

この制限を無効にするには、0 に設定します。

​

max_joined_block_size_bytes

JOIN結果の最大blockサイズ (バイト単位) です (join algorithm が対応している場合) 。0 は無制限を意味します。

​

max_joined_block_size_rows

JOIN結果の最大ブロックサイズ (JOINアルゴリズムが対応している場合) 。0 は無制限を意味します。

​

max_limit_for_vector_search_queries

この設定値を超える LIMIT を指定した SELECT クエリでは、ベクトル類似度インデックスを使用できません。ベクトル類似度インデックスでのメモリオーバーフローを防ぐのに役立ちます。

​

max_local_read_bandwidth

ローカル読み取りの最大速度 (1秒あたりのバイト数) です。

​

max_local_write_bandwidth

ローカルへの書き込みの最大速度 (1秒あたりのバイト数) 。

​

max_memory_usage

Cloud でのデフォルト値: レプリカ上の RAM の量によって異なります。

単一サーバー上でクエリを実行する際に使用できる RAM の最大量です。 値 0 は無制限を意味します。

この設定では、利用可能なメモリ容量やマシン全体のメモリ総量は考慮されません。この制限は、単一サーバー内の単一のクエリに適用されます。

SHOW PROCESSLIST を使用すると、各クエリの現在のメモリ消費量を確認できます。 各クエリのピークメモリ消費量は追跡され、ログに書き込まれます。

次の集約関数の String および Array 引数の状態については、 メモリ使用量は完全には追跡されません。

• min
• max
• any
• anyLast
• argMin
• argMax

メモリ消費量は、max_memory_usage_for_user および max_server_memory_usage のパラメータによっても制限されます。

​

max_memory_usage_for_user

1 台の server 上で、ユーザーのクエリ実行に使用できる RAM の最大量です。0 は無制限を意味します。

デフォルトでは、この値に制限はありません (max_memory_usage_for_user = 0) 。

max_memory_usage の説明もあわせて参照してください。

たとえば、clickhouse_read という名前のユーザーについて max_memory_usage_for_user を 1000 バイトに設定する場合は、次のステートメントを使用できます

ALTER USER clickhouse_read SETTINGS max_memory_usage_for_user = 1000;

クライアントからログアウトして再度ログインした後、getSetting 関数を使用すると、正しく動作したことを確認できます。

SELECT getSetting('max_memory_usage_for_user');

​

max_network_bandwidth

ネットワーク経由のデータ転送速度を、1秒あたりのバイト数で制限します。この設定はすべてのクエリに適用されます。

設定可能な値:

• 正の整数。
• 0 — 帯域幅の制御は無効です。

​

max_network_bandwidth_for_all_users

ネットワーク経由でのデータ転送速度を、1 秒あたりのバイト数で制限します。この設定は、サーバー上で同時実行されているすべてのクエリに適用されます。

設定可能な値:

• 正の整数。
• 0 — データ転送速度の制御は無効です。

​

max_network_bandwidth_for_user

ネットワーク経由のデータ転送速度を、1 秒あたりのバイト数で制限します。この設定は、1 人のユーザーが同時実行するすべてのクエリに適用されます。

設定可能な値:

• 正の整数。
• 0 — データ転送速度の制御は無効です。

​

max_network_bytes

クエリの実行時に、ネットワーク経由で受信または送信されるデータ量 (バイト単位) を制限します。この設定は、個々のクエリに適用されます。

設定可能な値:

• 正の整数。
• 0 — データ量の制限は無効です。

​

max_number_of_partitions_for_independent_aggregation

最適化を適用する対象となるテーブル内のパーティション数の上限

​

max_os_cpu_wait_time_ratio_to_throw

クエリの拒否を検討する際に基準とする、OS の CPU 待機時間 (OSCPUWaitMicroseconds メトリクス) とビジー時間 (OSCPUVirtualTimeMicroseconds メトリクス) の最大比率です。確率の計算には最小比率と最大比率の間の線形補間が使用され、この時点で確率は 1 になります。

​

max_parallel_replicas

クエリ実行時に、各分片で使用するレプリカの最大数です。

設定可能な値:

• 正の整数。

追加情報

このオプションは、使用する設定によって結果が異なります。

​

SAMPLE キーを使用した並列処理

クエリは、複数のサーバーで並列に実行すると、より高速に処理できる場合があります。ただし、次のような場合にはクエリパフォーマンスが低下することがあります。

• パーティション化キー内でのサンプリングキーの位置によっては、効率的な範囲スキャンを行えない。
• テーブルにサンプリングキーを追加すると、他のカラムでのフィルタリング効率が低下する。
• サンプリングキーが、計算コストの高い式である。
• クラスターのレイテンシ分布にロングテールがある場合、より多くのサーバーにクエリを送ると、クエリ全体のレイテンシが増加する。

​

parallel_replicas_custom_key を使用した並列処理

この設定は、あらゆるレプリケートテーブルで有用です。

​

max_parser_backtracks

パーサーの最大バックトラック回数 (再帰下降パースの過程で、別の候補を何回試すか) 。

​

max_parser_depth

再帰下降パーサーの最大再帰深度を制限します。スタックサイズの制御に使用できます。

設定可能な値:

• 正の整数。
• 0 — 再帰深度は無制限です。

​

max_parsing_threads

並列パースをサポートする入力フォーマットでデータをパースする際の最大スレッド数です。デフォルトでは、自動的に決定されます。

​

max_partition_size_to_drop

クエリ実行時にパーティションを削除する際の制限です。値 0 は、制限なくパーティションを削除できることを意味します。

Cloud でのデフォルト値: 1 TB。

このクエリ設定は、対応するサーバー設定を上書きします。詳しくは max_partition_size_to_drop を参照してください

​

max_partitions_per_insert_block

1つの挿入ブロック内のパーティション数の上限を制限します。 ブロックに含まれるパーティション数が多すぎる場合は、例外がスローされます。

• 正の整数。
• 0 — パーティション数は無制限。

詳細

データの挿入時に、ClickHouse は挿入されるブロック内の パーティション数を計算します。パーティション数が max_partitions_per_insert_block を超えると、 ClickHouse は throw_on_max_partitions_per_insert_block の設定に応じて警告をログに記録するか、 例外をスローします。例外メッセージは次のとおりです。

“単一の INSERT ブロックに対するパーティション数が多すぎます (partitions_count 個のパーティション、上限は ” + toString(max_partitions) + ”) 。 上限は ‘max_partitions_per_insert_block’ 設定によって制御されます。 大量のパーティションを使用するのは、よくある誤解です。これは深刻な パフォーマンス低下を引き起こし、server の起動の遅延、INSERT クエリの低速化、 および SELECT クエリの低速化につながります。table に推奨されるパーティション総数は 1000..10000 未満です。なお、パーティション化は SELECT クエリを高速化することを目的としたものではありません (範囲クエリを高速化するには ORDER BY key で十分です) 。 パーティションはデータ操作 (DROP PARTITION など) のためのものです。”

多数のパーティションを使用するのはよくある誤解であるため、この設定は安全しきい値として機能します。

​

max_partitions_to_read

1 回のクエリでアクセスできるパーティションの最大数を制限します。

テーブル作成時に指定した設定値は、クエリレベルの設定で上書きできます。

設定可能な値:

• 正の整数
• -1 - 無制限 (デフォルト)

この MergeTree 設定 max_partitions_to_read は、テーブル設定でも指定できます。

​

max_parts_to_move

1 回のクエリで移動できるパーツ数を制限します。0 は無制限を意味します。

​

max_projection_rows_to_use_projection_index

プロジェクション索引から読み取る行数がこのしきい値以下であれば、ClickHouse はクエリ実行時にプロジェクション索引の適用を試みます。

​

max_query_size

SQLパーサーが解析するクエリ文字列の最大バイト数です。 INSERT クエリの VALUES 句内のデータは、別個のストリームパーサー (O(1) の RAM を使用) によって処理されるため、この制限の影響を受けません。

ClickHouse はクエリを解析するためのバッファを確保する必要があり、そのバッファサイズは max_query_size 設定によって決まります。そのため、max_query_size は SQL クエリ内 (例: SELECT now() SETTINGS max_query_size=10000) では設定できません。この設定はクエリの実行前に構成しておく必要があります。

​

max_rand_distribution_parameter

randChiSquared、randStudentT、randFisherF などの random distribution functions における、分布の shape parameter の最大値です。これにより、極端な parameter 値によって計算時間が極端に長くなるのを防ぎます。

​

max_rand_distribution_trials

randBinomial や randNegativeBinomial などの random distribution functions で許可される試行回数の最大値です。これにより、試行回数が大きい場合でも計算時間が極端に長くなるのを防ぎます。

​

max_read_buffer_size

filesystem から読み取る際の buffer の最大サイズ。

​

max_read_buffer_size_local_fs

ローカルfilesystemから読み込む際のbufferの最大サイズです。0 に設定すると、max_read_buffer_size が使用されます。

​

max_read_buffer_size_remote_fs

リモートファイルシステムから読み取るためのバッファの最大サイズです。0 に設定した場合は、max_read_buffer_size が使用されます。

​

max_recursive_cte_evaluation_depth

再帰CTEの評価深度の最大値

​

max_remote_read_network_bandwidth

読み取り時のネットワーク経由のデータ転送の最大速度を、1秒あたりのバイト数で指定します。

​

max_remote_write_network_bandwidth

書き込み時の、ネットワーク経由のデータ転送の最大速度をバイト/秒で指定します。

​

max_replica_delay_for_distributed_queries

分散クエリで、遅延しているレプリカを使用しないようにします。レプリケーション を参照してください。

時間を秒単位で設定します。レプリカの遅延が設定値以上の場合、そのレプリカは使用されません。

設定可能な値:

• 正の整数。
• 0 — レプリカの遅延はチェックされません。

遅延が 0 でないレプリカを一切使用しないようにするには、このパラメータを 1 に設定します。

レプリケートテーブルを参照する分散テーブルに対して SELECT を実行する際に使用されます。

​

max_result_bytes

結果サイズをバイト単位 (非圧縮) で制限します。しきい値に達した場合、クエリはデータのブロックを処理し終えた後に停止しますが、 結果の最後のブロックは切り詰められないため、結果サイズがしきい値を超えることがあります。

注意事項

このしきい値では、メモリ内の結果サイズが考慮されます。 結果サイズ自体が小さくても、メモリ内のより大きなデータ構造、 つまり LowCardinality カラムの辞書や AggregateFunction カラムのアリーナを参照している場合があるため、 結果サイズが小さくても、しきい値を超えることがあります。

この設定はかなり低レベルなため、使用には注意してください

​

max_result_rows

Cloud でのデフォルト値: 0。

結果の行数を制限します。サブクエリに対してもチェックされ、分散クエリの一部を実行する際はリモートサーバー上でもチェックされます。 値が 0 の場合、制限は適用されません。

しきい値に達すると、クエリはデータの block の処理が終わった時点で停止しますが、 結果の最後の block は切り詰められないため、結果サイズが しきい値を上回ることがあります。

​

max_reverse_dictionary_lookup_cache_size_bytes

関数 dictGetKeys が使用するクエリ単位の逆引き Dictionary ルックアップ cache の最大サイズ (バイト単位) 。この cache には、同一クエリ内で Dictionary を再スキャンしないよう、属性値ごとにシリアライズされたキー Tuple が保存されます。上限に達すると、エントリは LRU に従って追い出されます。0 に設定すると cache は無効になります。

​

max_rows_for_lazy_final

lazy FINAL 最適化で使用するセット内の最大行数。これを超えると、通常の FINAL にフォールバックします。

​

max_rows_in_distinct

DISTINCT 使用時の、異なる行の最大数です。

​

max_rows_in_join

テーブルの結合時に使用される右側のデータ構造 (通常はハッシュ テーブル) 内の行数を制限します。

この設定は、SELECT … JOIN 操作および Join テーブルエンジンに適用されます。

1 つのクエリに複数の JOIN が含まれている場合、ClickHouse は中間結果ごとにこの設定を確認します。制限に達した場合の動作は、選択した join_algorithm に依存します。アルゴリズムごとの動作 (spill、再パーティション、 切り替え、または join_overflow_mode に従った throw/break) については、その設定を参照してください。

設定可能な値:

• 正の整数。
• 0 — 行数は無制限です。

​

max_rows_in_set

サブクエリから作成される IN 句内のデータセットに含められる最大行数。

​

max_rows_in_set_to_optimize_join

結合前に、互いの行セットを使って結合対象のテーブルを絞り込む際の Set の最大サイズ。

設定可能な値:

• 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 に設定されています。

​

max_rows_to_transfer

GLOBAL IN/JOIN セクションの実行時に、リモートサーバーに渡したり、一時テーブルに保存したりできる最大サイズ (行数) 。

​

max_sessions_for_user

認証済みユーザーごとに ClickHouse server で同時に使用できるセッションの最大数です。

例:

<profiles>
    <single_session_profile>
        <max_sessions_for_user>1</max_sessions_for_user>
    </single_session_profile>
    <two_sessions_profile>
        <max_sessions_for_user>2</max_sessions_for_user>
    </two_sessions_profile>
    <unlimited_sessions_profile>
        <max_sessions_for_user>0</max_sessions_for_user>
    </unlimited_sessions_profile>
</profiles>
<users>
    <!-- ユーザーAliceはClickHouseサーバーに同時に接続できるのは1回までです。 -->
    <Alice>
        <profile>single_session_user</profile>
    </Alice>
    <!-- ユーザーBobは同時に2つのセッションを使用できます。 -->
    <Bob>
        <profile>two_sessions_profile</profile>
    </Bob>
    <!-- ユーザーCharlesは同時セッション数に制限なく使用できます。 -->
    <Charles>
        <profile>unlimited_sessions_profile</profile>
    </Charles>
</users>

設定可能な値:

• 正の整数
• 0 - 同時セッション数は無制限 (デフォルト)

​

max_size_to_preallocate_for_aggregation

集約前に、すべてのハッシュテーブルで合計して事前確保できる要素数

​

max_size_to_preallocate_for_joins

JOIN の前に、すべてのハッシュテーブル全体で合計何要素まで領域を事前確保できるか

​

max_skip_unavailable_shards_num

skip_unavailable_shards が有効な場合、エラーを出さずにスキップできる分片の最大数を制限します。 利用できない分片の数がこの値を超えると、エラーを出さずにスキップする代わりに例外がスローされます。

値が 0 の場合は制限なしを意味します (既定の動作では、利用できないすべての分片をスキップできます) 。

​

max_skip_unavailable_shards_ratio

skip_unavailable_shards が有効な場合、暗黙的にスキップできる分片の最大比率 (0～1) を制限します。 使用不可の分片の総分片数に対する比率がこの値を超えると、暗黙的にスキップする代わりに例外がスローされます。

値が 0 の場合は制限がないことを意味します (デフォルトの動作では、使用不可の分片をすべてスキップできます) 。

​

max_streams_for_files_processing_in_cluster_functions

0 以外の場合、Cluster table functions でファイルからデータを読み取るスレッド数を制限します。

​

max_streams_for_merge_tree_reading

0 以外の場合、MergeTree テーブルの読み取りストリーム数を制限します。

​

max_streams_for_union_step

UNION ステップで同時にアクティブになるデータストリーム数を制限します (UNION DISTINCT は UNION ALL ステップの後に DISTINCT ステップを続ける形で実装されているため、UNION ALL と UNION DISTINCT の両方に適用されます) 。UNION クエリに多数のサブクエリがある場合、それらはすべて同時に読み取りバッファを開くため、メモリ使用量はサブクエリ数に比例して増加します。この設定では Concat プロセッサを挿入してパイプラインの幅を絞り、同時にアクティブなストリーム数を最大でこの値までに抑えることで、ピークメモリを大幅に削減します。実際の上限は、この値と max_threads * max_streams_for_union_step_to_max_threads_ratio の小さい方です (いずれかが 0 の場合は無視されます) 。両方が 0 の場合、パイプラインの絞り込みは適用されません。また、クエリプランで UNION の各出力ストリームをそれぞれ個別にソート済みの状態に保つ必要がある場合 (たとえば、read-in-order 最適化が UNION 全体に適用される場合) にも、この上限は適用されません。その場合は順序の正しさが優先されるため、絞り込みはスキップされます。

​

max_streams_for_union_step_to_max_threads_ratio

この比率に max_threads を掛けた値によって、UNION ステップで同時にアクティブにできるストリーム数の上限が決まります (UNION ALL と UNION DISTINCT の両方に適用されます) 。実際の上限は、この計算値と max_streams_for_union_step のうち小さい方です (どちらか一方が 0 の場合は無視されます) 。たとえば、max_threads = 8 でこの比率を 1 に設定すると、アクティブになるストリームは最大 8 個です。この比率ベースの上限を無効にするには、0 に設定します。max_streams_for_union_step と同様に、クエリプランで UNION の各出力ストリームをそれぞれソート済みの状態に保つ必要がある場合、この上限は適用されません。

​

max_streams_multiplier_for_merge_tables

Merge テーブルから読み取る際に、より多くのストリームを要求します。ストリームは、Merge テーブルが使用する各テーブルに分散されます。これにより、作業をスレッド間でより均等に分散でき、特に構成テーブルのサイズが異なる場合に効果的です。

​

max_streams_to_max_threads_ratio

スレッド数を超える数のソースを使用できるようにし、処理を各スレッドにより均等に分散できるようにします。これは一時的な対策であることを前提としています。将来的には、ソース数をスレッド数と同じにしたうえで、各ソースが利用可能な処理を動的に選択できるようになるためです。

​

max_subquery_depth

クエリに、指定した数を超えるネストしたサブクエリがある場合、 例外をスローします。

これにより、クラスターのユーザーが過度に複雑なクエリを記述するのを防ぐための 妥当性チェックを行えます。

​

max_table_size_to_drop

クエリ実行時にテーブルを削除する際の制限です。値 0 は、制限なくすべてのテーブルを削除できることを意味します。

Cloud でのデフォルト値: 1 TB。

このクエリ設定は、対応するサーバー設定を上書きします。詳しくは max_table_size_to_drop を参照してください

​

max_temporary_columns

クエリの実行時に、定数カラムを含めて同時に RAM に保持される一時カラムの最大数です。中間計算の結果として、クエリがメモリ内に指定された数を超える一時カラムを生成した場合は、例外が発生します。

この設定は、過度に複雑なクエリを防ぐのに役立ちます。

0 は無制限を意味します。

​

max_temporary_data_on_disk_size_for_query

同時実行されているすべてのクエリにおいて、ディスク上の一時ファイルが消費するデータ量の上限 (バイト単位) 。

設定可能な値:

• 正の整数。
• 0 — 無制限 (デフォルト)

​

max_temporary_data_on_disk_size_for_user

同時実行中のすべてのユーザークエリにおいて、ディスク上の一時ファイルが消費できるデータ量の上限 (バイト単位) 。

設定可能な値:

• 正の整数。
• 0 — 無制限 (デフォルト)

​

max_temporary_non_const_columns

max_temporary_columns と同様に、クエリ実行時に定数カラムを除いて、同時に RAM に保持する必要がある一時カラムの最大数を指定します。

定数カラムはクエリ実行時にかなり頻繁に生成されますが、必要な計算リソースはほぼゼロです。

​

max_threads

リモートサーバーからデータを取得するためのスレッド (‘max_distributed_connections’ パラメータを参照) を除く、クエリ処理スレッドの最大数です。

このパラメータは、クエリ処理パイプラインの同じ段階を並列に実行するスレッドに適用されます。 たとえば、テーブルの読み取り時に、少なくとも ‘max_threads’ 個のスレッドを使って、関数を含む式の評価、WHERE によるフィルタリング、GROUP BY の事前集約を並列に実行できる場合は、‘max_threads’ が使用されます。

LIMIT によってすぐに完了するクエリでは、‘max_threads’ をより小さく設定できます。 たとえば、必要な数のエントリがすべてのブロックに存在し、max_threads = 8 の場合、実際には 1 ブロックだけ読めば十分であっても、8 ブロックが取得されます。 max_threads の値が小さいほど、消費メモリは少なくなります。

max_threads 設定のデフォルト値は、ClickHouse で利用可能なハードウェアスレッド数 (CPU コア数) に一致します。 特別なケースとして、32 CPU コア未満で SMT (例: Intel HyperThreading) を備えた x86 プロセッサでは、ClickHouse はデフォルトで論理コア数 (= 物理コア数 x 2) を使用します。

SMT (例: Intel HyperThreading) がない場合、これは CPU コア数に対応します。

ClickHouse Cloud ユーザーの場合、デフォルト値は auto(N) と表示され、N はサービスの vCPU サイズ (たとえば 2vCPU/8GiB、4vCPU/16GiB など) に一致します。 すべてのサービスサイズの一覧は、Cloud Console の Settings タブを参照してください。

​

max_threads_for_indexes

索引の処理に使用するスレッドの最大数です。

​

max_threads_min_free_memory_per_thread

サーバーがメモリ逼迫状態にある場合、max_threads を引き下げ、メモリ制限に達する可能性が高い高並列のクエリが開始されるのを防ぎます。

空きメモリは、サーバーの max_server_memory_usage から、グローバルメモリトラッカーによって現在追跡されているメモリ使用量を差し引いて算出されます。この空きメモリが max_threads にこの値を掛けた値より少ない場合、N * value <= free_memory を満たす最大の N になるように max_threads が減らされます。最小値は 1 です。

この制限を無効にするには、0 に設定します。

たとえば、デフォルト値の 1 GiB で空きメモリが 32 GiB の場合、max_threads の上限は 32 になります。空きメモリが 1 GiB の場合は 1 まで下がります。

この設定は、読み取り側の並列度 (SELECT、UNION、INTERSECT/EXCEPT、および INSERT ... SELECT の SELECT 側) に適用されます。書き込み側については、max_insert_threads_min_free_memory_per_thread を参照してください。

​

max_untracked_memory

小さな割り当てと解放はスレッドローカル変数にまとめられ、その量 (絶対値) が指定した値を超えた場合にのみ追跡またはプロファイルされます。値が ‘memory_profiler_step’ より大きい場合は、実質的に ‘memory_profiler_step’ まで引き下げられます。

​

max_wkb_geometry_elements

readWKB および関連関数でのパース時に、1 つの WKB geometry 要素内で許可される point、ring、または Polygon の最大数です。これにより、不正な WKB データによる過剰なメモリ割り当てを防ぎます。ハードコードされた上限 (1 億) を使用するには、0 に設定します。

​

memory_overcommit_ratio_denominator

これは、グローバルレベルでハード制限に達したときのソフトメモリ制限を表します。 この値は、クエリの overcommit ratio を算出するために使用されます。 0 は、そのクエリをスキップすることを意味します。 詳細は、メモリオーバーコミットを参照してください。

​

memory_overcommit_ratio_denominator_for_user

これは、ユーザーレベルでハード制限に達したときのソフトメモリ制限を表します。 この値は、クエリのオーバーコミット比率の計算に使用されます。 0 は、そのクエリをスキップすることを意味します。 メモリオーバーコミットの詳細を参照してください。

​

memory_profiler_sample_max_allocation_size

指定した値以下のサイズのランダムな割り当てを、memory_profiler_sample_probability と同じ確率で収集します。0 は無効を意味します。このしきい値が想定どおりに機能するよう、‘max_untracked_memory’ を 0 に設定するとよい場合があります。

​

memory_profiler_sample_min_allocation_size

指定した値以上のサイズの割り当てを、memory_profiler_sample_probability で指定した確率でランダムに収集します。0 は無効です。このしきい値が想定どおりに機能するように、max_untracked_memory を 0 に設定することをおすすめします。

​

memory_profiler_sample_probability

ランダムな割り当てと解放を収集し、trace_type が ‘MemorySample’ のものとして system.trace_log に書き込みます。この確率は、割り当てサイズに関係なく、すべての alloc/free に対して適用されます (memory_profiler_sample_min_allocation_size と memory_profiler_sample_max_allocation_size で変更できます) 。サンプリングは、未追跡メモリ量が ‘max_untracked_memory’ を超えた場合にのみ行われる点に注意してください。より細かい粒度でサンプリングしたい場合は、‘max_untracked_memory’ を 0 に設定するとよいでしょう。

​

memory_profiler_step

メモリプロファイラのステップを設定します。クエリのメモリ使用量がバイト数で次の各ステップを超えるたびに、メモリプロファイラは割り当て時のスタックトレースを収集し、trace_log に書き込みます。

設定可能な値:

• 正の整数 (バイト数) 。

• メモリプロファイラを無効にする場合は 0。

​

memory_tracker_fault_probability

exception safety をテストするための設定です。指定した確率で、メモリを割り当てるたびに例外をスローします。

​

memory_usage_overcommit_max_wait_microseconds

ユーザーレベルでメモリオーバーコミットが発生した場合に、メモリが解放されるまでスレッドが待機する最大時間です。 タイムアウトに達してもメモリが解放されない場合は、例外がスローされます。 詳しくは、メモリオーバーコミットを参照してください。

​

merge_table_max_tables_to_look_for_schema_inference

明示的なスキーマを指定せずにMergeテーブルを作成する場合、またはmergeテーブル関数を使用する場合、スキーマは一致するテーブルのうち、指定した数を超えない範囲でユニオンとして推論されます。 テーブル数がそれを超える場合、スキーマは先頭から指定した数のテーブルに基づいて推論されます。

​

merge_tree_coarse_index_granularity

データを検索する際、ClickHouse は索引ファイル内のデータマークを確認します。必要なキーが特定の範囲内にあると判断すると、その範囲を merge_tree_coarse_index_granularity 個の部分範囲に分割し、それらの中から必要なキーを再帰的に検索します。

設定可能な値:

• 任意の正の偶数整数。

​

merge_tree_compact_parts_min_granules_to_multibuffer_read

ClickHouse Cloud でのみ有効です。並列読み取りと prefetch をサポートする multibuffer reader を使用するために必要な、MergeTree テーブルの compact パーツ内のストライプあたりの granules 数です。remote fs から読み取る場合、multibuffer reader を使用すると読み取りリクエスト数が増加します。

​

merge_tree_determine_task_size_by_prewhere_columns

読み取りタスクのサイズを決定する際に、prewhere カラムのサイズだけを使用するかどうか。

​

merge_tree_max_bytes_to_use_cache

ClickHouse が 1 回のクエリで merge_tree_max_bytes_to_use_cache バイトを超えるデータを読み取る必要がある場合、非圧縮ブロックのキャッシュは使用されません。

非圧縮ブロックのキャッシュには、クエリ用に抽出されたデータが格納されます。ClickHouse は、このキャッシュを使用して、繰り返し実行される小規模なクエリへの応答を高速化します。この設定は、大量のデータを読み取るクエリによってキャッシュが不要に消費されるのを防ぎます。uncompressed_cache_size サーバー設定で、非圧縮ブロックのキャッシュのサイズを定義します。

設定可能な値:

• 任意の正の整数。

​

merge_tree_max_rows_to_use_cache

ClickHouse が 1 回のクエリで merge_tree_max_rows_to_use_cache 行を超えて読み取る場合、非圧縮ブロックのキャッシュは使用されません。

非圧縮ブロックのキャッシュには、クエリのために取り出されたデータが保存されます。ClickHouse はこのキャッシュを使って、繰り返し実行される小規模なクエリへの応答を高速化します。この設定は、大量のデータを読み取るクエリによってキャッシュが使い潰されるのを防ぎます。uncompressed_cache_size サーバー設定で、非圧縮ブロックのキャッシュのサイズを定義します。

設定可能な値:

• 任意の正の整数。

​

merge_tree_min_bytes_for_concurrent_read

MergeTree エンジンのテーブルで、1つのファイルから読み取るバイト数が merge_tree_min_bytes_for_concurrent_read を超える場合、ClickHouse はそのファイルを複数のスレッドで同時に読み取ろうとします。

指定可能な値:

• 正の整数。

​

merge_tree_min_bytes_for_concurrent_read_for_remote_filesystem

リモートファイルシステムから読み取る際に、MergeTree エンジンが読み取りを並行化できるようになるまでに、1 つのファイルから読み取る必要がある最小バイト数です。この設定の使用は推奨されません。

設定可能な値:

• 正の整数。

​

merge_tree_min_bytes_for_seek

1 つのファイル内で読み取る 2 つのデータブロック間の距離が merge_tree_min_bytes_for_seek バイト未満の場合、ClickHouse は余分な seek を避けるため、両方のブロックを含むファイル範囲を連続して読み取ります。

設定可能な値:

• 任意の正の整数。

​

merge_tree_min_bytes_per_task_for_remote_reading

別名: filesystem_prefetch_min_bytes_for_single_read_task

タスクごとに読み取る最小バイト数。

​

merge_tree_min_read_task_size

タスクサイズの厳密な下限 (granule 数が少なく、利用可能なスレッド数が多い場合でも、これより小さいタスクは割り当てられません

​

merge_tree_min_rows_for_concurrent_read

MergeTree テーブルのファイルから読み取る行数が merge_tree_min_rows_for_concurrent_read を超えると、ClickHouse はこのファイルを複数のスレッドで同時に読み取ろうとします。

設定可能な値:

• 正の整数。

​

merge_tree_min_rows_for_concurrent_read_for_remote_filesystem

リモートファイルシステムから読み取る際に、MergeTree エンジンが読み取りを並列化できるようになるまでに、1つのファイルから読み取る最小の行数です。この設定の使用は推奨されません。

設定可能な値:

• 正の整数。

​

merge_tree_min_rows_for_seek

1 つのファイル内で読み取る 2 つのデータブロック間の距離が merge_tree_min_rows_for_seek 行より小さい場合、ClickHouse はファイル内でシークせず、データを順次読み取ります。

設定可能な値:

• 任意の正の整数。

​

merge_tree_read_split_ranges_into_intersecting_and_non_intersecting_injection_probability

PartsSplitter のテストのため、指定した確率で、MergeTree から読み取るたびに読み取り範囲を交差するものと交差しないものに分割します。

​

merge_tree_storage_snapshot_sleep_ms

MergeTree テーブルのストレージスナップショットを作成する際に、人為的な遅延 (ミリ秒) を挿入します。 テストおよびデバッグ目的でのみ使用します。

設定可能な値:

• 0 - 遅延なし (デフォルト)
• N - ミリ秒単位の遅延

​

merge_tree_use_const_size_tasks_for_remote_reading

リモートテーブルからの読み取りに、一定サイズのタスクを使用するかどうか。

​

merge_tree_use_deserialization_prefixes_cache

MergeTree でリモートディスクから読み取る際に、ファイルのプレフィックスに含まれるカラムメタデータの cache を有効にします。

​

merge_tree_use_prefixes_deserialization_thread_pool

MergeTree の wide パーツにおけるプレフィックスの並列読み取り用スレッドプールの使用を有効にします。このスレッドプールのサイズは、サーバー設定 max_prefixes_deserialization_thread_pool_size で制御されます。

​

merge_tree_use_v1_object_and_dynamic_serialization

有効にすると、MergeTree では JSON 型および Dynamic 型に対して、V2 ではなく V1 シリアライゼーション バージョンが使用されます。この設定の変更は、サーバーの再起動後にのみ反映されます。

​

metrics_perf_events_enabled

有効にすると、一部の perf イベントがクエリの実行中を通して計測されます。

​

metrics_perf_events_list

クエリの実行中を通して測定される perf メトリクスのカンマ区切りリストです。空の場合は、すべてのイベントが対象になります。利用可能なイベントについては、sources 内の PerfEventInfo を参照してください。

​

min_bytes_to_use_direct_io

ストレージディスクへのダイレクト I/O アクセスを使用するために必要な最小データ量です。

ClickHouse は、テーブルからデータを読み取る際にこの設定を使用します。読み取るすべてのデータの合計ストレージ容量が min_bytes_to_use_direct_io バイトを超える場合、ClickHouse は O_DIRECT オプションを使用してストレージディスクからデータを読み取ります。

設定可能な値:

• 0 — ダイレクト I/O は無効です。
• 正の整数。

​

min_bytes_to_use_mmap_io

これは実験的な設定です。カーネルからユーザー空間へデータをコピーせずに大きなファイルを読み込むための最小メモリ量を設定します。mmap/munmap は低速なため、推奨されるしきい値は約 64 MB です。これは大きなファイルでのみ有効で、データがページキャッシュ上にある場合にのみ効果があります。

設定可能な値:

• 正の整数。
• 0 — 大きなファイルも、カーネルからユーザー空間へデータをコピーする方式でのみ読み込まれます。

​

min_chunk_bytes_for_parallel_parsing

• 型: unsigned int
• デフォルト値: 1 MiB

各スレッドが並列にパースする最小のchunkサイズ (バイト単位) です。

​

min_compress_block_size

MergeTree テーブル向けの設定です。クエリ処理時のレイテンシを低減するため、サイズが min_compress_block_size 以上の block は、次の mark の書き込み時に圧縮されます。デフォルト値は 65,536 です。

非圧縮データが max_compress_block_size 未満の場合、実際の block サイズはこの値以上であり、かつ 1 つの mark 分のデータ量を下回ることはありません。

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

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

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

これは上級者向けの設定です。ClickHouse を使い始めたばかりであれば、変更しないでください。

​

min_count_to_compile_aggregate_expression

JIT コンパイルを開始するために必要な、同一の集約式の最小回数です。compile_aggregate_expressions 設定が有効な場合にのみ機能します。

設定可能な値:

• 正の整数。
• 0 — 同一の集約式は常に JIT コンパイルされます。

​

min_count_to_compile_expression

同じ式がコンパイルされるまでに必要な最小実行回数。

​

min_count_to_compile_sort_description

JITコンパイルが行われるまでに同一のソート記述が現れる回数

​

min_execution_speed

1秒あたりの行数で表される最小実行速度です。各データブロックで timeout_before_checking_execution_speed が経過した時点でチェックされます。実行速度がこれを下回る場合、例外が発生します。

​

min_execution_speed_bytes

1 秒あたりの実行バイト数の最小値です。 timeout_before_checking_execution_speed の期限が切れると、各データブロックごとにチェックされます。実行速度がこれを下回る場合は、例外がスローされます。

​

min_external_table_block_size_bytes

ブロックのサイズが十分でない場合、外部テーブルに渡すブロックを指定したバイト数になるようにまとめます。

​

min_external_table_block_size_rows

ブロックのサイズが十分でない場合、external table に渡すブロックを指定した行数になるようにまとめる。

​

min_filtered_ratio_for_lazy_final

lazy FINAL 最適化において、索引解析によってフィルタリングされるマークの最小比率です。フィルタリングされるマークの割合がこの値未満の場合は、通常の FINAL にフォールバックします。値 0 を指定すると、このチェックは無効になります。

​

min_free_disk_bytes_to_perform_insert

insert を実行するために必要な最小の空きディスク容量 (バイト数) 。

​

insert を実行するための最小空きディスク容量比率

insert を実行するために必要な最小空きディスク容量の比率です。

​

min_free_disk_space_for_temporary_data

外部ソートや集約で使用する一時データの書き込み時に確保しておく最小のディスク空き容量です。

​

min_hit_rate_to_use_consecutive_keys_optimization

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

​

min_insert_block_size_bytes

テーブルに挿入する際に形成されるブロックの最小サイズ (バイト単位) 。

この設定は min_insert_block_size_rows とあわせて機能し、同じコンテキスト (フォーマットのパースと INSERT 操作) でのブロック形成を制御します。これらの設定がいつどのように適用されるかについて詳しくは、min_insert_block_size_rows を参照してください。

設定可能な値:

• 正の整数。
• 0 — この設定はブロック形成に使用されません。

​

min_insert_block_size_bytes_for_materialized_views

INSERTクエリでテーブルに挿入できるブロックの最小バイト数を設定します。これより小さいブロックは、より大きなブロックにまとめられます。この設定は、materialized view に挿入されるブロックにのみ適用されます。この設定を調整することで、materialized view への書き込み時のブロックのまとめ方を制御し、過剰なメモリ使用量を回避できます。

設定可能な値:

• 任意の正の整数。
• 0 — まとめる処理は無効です。

関連項目

• min_insert_block_size_bytes

​

min_insert_block_size_rows

テーブルに挿入するために形成されるブロックの最小サイズ (行数) です。

この設定は、次の 2 つの文脈におけるブロック形成を制御します。

1. フォーマットのパース: サーバーが任意のインターフェイス (HTTP、インラインデータを使用する clickhouse-client、gRPC、PostgreSQL ワイヤプロトコル) から行ベースの入力フォーマット (CSV、TSV、JSONEachRow など) をパースする際、ブロックは次の場合に出力されます。

   • min_insert_block_size_rows と min_insert_block_size_bytes の両方に達した場合、または
   • max_insert_block_size_rows または max_insert_block_size_bytes のいずれかに達した場合

   注: clickhouse-client または clickhouse-local を使用してファイルから読み取る場合、データはクライアント自身がパースするため、この設定はクライアント側で適用されます。

2. INSERT 操作: INSERT クエリの実行時、およびデータが materialized view を通過する際、この設定の動作は use_strict_insert_block_limits に依存します。

   • 有効な場合: ブロックは次の場合に出力されます。

     • 最小しきい値 (AND) : min_insert_block_size_rows と min_insert_block_size_bytes の両方に達したとき
     • 最大しきい値 (OR) : max_insert_block_size_rows または max_insert_block_size_bytes のいずれかに達したとき

   • 無効 (デフォルト) の場合: min_insert_block_size_rows または min_insert_block_size_bytes に達するとブロックが出力されます。max_insert_block_size の設定は適用されません。

設定可能な値:

• 正の整数。
• 0 — この設定はブロック形成に関与しません。

​

min_insert_block_size_rows_for_materialized_views

INSERT クエリでテーブルに挿入できるブロックの最小行数を設定します。これより小さいブロックは、より大きなブロックにまとめられます。この設定は、materialized view に挿入されるブロックにのみ適用されます。この設定を調整することで、materialized view への書き込み時のブロックのまとめ方を制御し、過剰なメモリ使用量を回避できます。

設定可能な値:

• 任意の正の整数。
• 0 — まとめる処理を無効にします。

関連項目

• min_insert_block_size_rows

​

min_joined_block_size_bytes

JOIN の入力ブロックおよび出力ブロックの最小サイズ (バイト単位) です (JOIN アルゴリズムが対応している場合) 。小さいブロックはまとめられます。0 は無制限を意味します。

​

min_joined_block_size_rows

JOIN の入力および出力ブロックの最小行数です (JOINアルゴリズムが対応している場合) 。小さいブロックはまとめられます。0 は無制限を意味します。

​

min_os_cpu_wait_time_ratio_to_throw

クエリを拒否するかどうかを判定する際の、OS の CPU 待機時間 (OSCPUWaitMicroseconds メトリクス) とビジー時間 (OSCPUVirtualTimeMicroseconds メトリクス) の最小比率です。確率の計算には最小比率と最大比率の間で線形補間が使用され、この時点での確率は 0 です。

​

min_outstreams_per_resize_after_split

パイプライン生成時に分割が行われた後の、Resize または StrictResize プロセッサの出力ストリーム数の最小値を指定します。結果のストリーム数がこの値未満の場合、分割操作は実行されません。

​

Resize ノードとは

Resize ノードは、クエリパイプライン内を流れるデータストリームの数を調整するプロセッサです。複数のスレッドやプロセッサにワークロードを均等に配分できるよう、ストリーム数を増やしたり減らしたりできます。たとえば、クエリでより高い並列度が必要な場合、Resize ノードは 1 つのストリームを複数のストリームに分割できます。逆に、複数のストリームを少数のストリームにマージして、データ処理を集約することもできます。

Resize ノードは、データブロックの構造を維持したまま、データが各ストリームに均等に分散されるようにします。これにより、リソース利用を最適化し、クエリパフォーマンスを向上させることができます。

​

Resize ノードを分割する必要がある理由

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

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

​

Resize ノードがどのように分割されるか

1. 分割を実行できることを確認するため、出力ストリーム数をチェックします。各分割 processor の出力ストリーム数が、min_outstreams_per_resize_after_split のしきい値以上である必要があります。
2. Resize ノードは、入力ストリームと出力ストリームの一部をそれぞれ処理する、同数のポートを持つ小さな Resize ノードに分割されます。
3. 各グループは独立して処理されるため、ロック競合が軽減されます。

​

任意の入出力を持つ Resize ノードの分割

入出力の数が、分割後の Resize ノード数で割り切れない場合には、一部の入力が NullSource に接続され、一部の出力が NullSink に接続されることがあります。これにより、データフロー全体に影響を与えることなく分割を行えます。

​

設定の目的

min_outstreams_per_resize_after_split 設定は、Resize ノードの分割が意味のあるものになるようにし、ストリーム数が少なすぎることで並列処理が非効率になるのを防ぎます。出力ストリーム数の最小値を設けることで、この設定は並列度とオーバーヘッドのバランスを保ち、ストリームの分割やマージを伴うシナリオでクエリ実行を最適化するのに役立ちます。

​

設定を無効にする

Resize ノードの分割を無効にするには、この設定を 0 にします。これにより、パイプラインの生成時に Resize ノードが分割されなくなり、より小さなノードに分けられることなく、元の構造を維持できます。

​

min_table_rows_to_use_projection_index

テーブルから読み取ると推定される行数がこのしきい値以上である場合、ClickHouse はクエリの実行時にプロジェクション索引の使用を試みます。

​

mongodb_throw_on_unsupported_query

有効な場合、MongoDB クエリを構築できないとき、MongoDB テーブルはエラーを返します。無効な場合、ClickHouse はテーブル全体を読み込んでローカルで処理します。このオプションは、‘allow_experimental_analyzer=0’ の場合は適用されません。

​

move_all_conditions_to_prewhere

適用可能なすべての条件を WHERE から PREWHERE に移動します

​

move_primary_key_columns_to_end_of_prewhere

主キーカラムを含む PREWHERE 条件を、AND チェーンの末尾に移動します。これらの条件は主キーの解析時に考慮される可能性が高いため、PREWHERE のフィルタリングにはあまり寄与しないと考えられます。

​

multiple_joins_try_to_keep_original_names

複数の JOIN の書き換え時に、最上位の式リストに別名を追加しない

​

mutations_execute_nondeterministic_on_initiator

true の場合、定数の非決定論的関数 (例: now() 関数) はイニシエーター上で実行され、UPDATE および DELETE クエリ内でリテラルに置き換えられます。これにより、定数の非決定論的関数を含む mutation の実行時に、レプリカ間でデータの同期を保つことができます。デフォルト値: false。

​

mutations_execute_subqueries_on_initiator

true の場合、スカラーサブクエリはイニシエーターで実行され、UPDATE および DELETE クエリではリテラルに置き換えられます。デフォルト値: false。

​

mutations_max_literal_size_to_replace

UPDATE および DELETE クエリで置換するシリアライズ済みリテラルの最大サイズ (バイト単位) 。上記 2 つの設定のうち少なくとも 1 つが有効な場合にのみ適用されます。デフォルト値: 16384 (16 KiB) 。

​

mutations_sync

ALTER TABLE ... UPDATE|DELETE|MATERIALIZE INDEX|MATERIALIZE PROJECTION|MATERIALIZE COLUMN|MATERIALIZE STATISTICS クエリ (mutations) を同期的に実行できるようにします。

設定可能な値:

値	説明
0	ミューテーションは非同期で実行されます。
1	クエリは、現在のサーバー上ですべてのミューテーションが完了するまで待機します。
2	クエリは、すべてのレプリカ (存在する場合) でのミューテーションが完了するまで待機します。
3	クエリはアクティブなレプリカのみを待機します。SharedMergeTree でのみサポートされます。ReplicatedMergeTree では mutations_sync = 2 と同じ動作になります。

​

mysql_datatypes_support_level

MySQL の型を、対応する ClickHouse の型へどのように変換するかを定義します。decimal、datetime64、date2Date32、date2String を任意に組み合わせたカンマ区切りのリストで指定します。最新のマッピング (decimal、datetime64、date2Date32) はデフォルトで有効です。

• decimal: 精度の範囲内であれば、NUMERIC 型と DECIMAL 型を Decimal に変換します。
• datetime64: 精度が 0 でない場合、DATETIME 型と TIMESTAMP 型を DateTime ではなく DateTime64 に変換します。
• date2Date32: DATE を Date ではなく Date32 に変換します。date2String より優先されます。
• date2String: DATE を Date ではなく String に変換します。datetime64 が優先されます。

​

mysql_map_fixed_string_to_text_in_show_columns

有効にすると、FixedString の ClickHouse データ型が SHOW COLUMNS で TEXT として表示されます。

MySQL wire protocol 経由で接続した場合にのみ効果があります。

• 0 - BLOB を使用します。
• 1 - TEXT を使用します。

​

mysql_map_string_to_text_in_show_columns

有効にすると、ClickHouse の String データ型は、SHOW COLUMNS で TEXT として表示されます。

この設定は、MySQL wire protocol 経由で接続した場合にのみ有効です。

• 0 - BLOB を使用します。
• 1 - TEXT を使用します。

​

mysql_max_rows_to_insert

MySQL ストレージエンジンの MySQL バッチ挿入における最大行数

​

network_compression_method

クライアント/サーバー間およびサーバー/サーバー間の通信を圧縮するためのコーデックです。

設定可能な値:

• NONE — 圧縮しません。
• LZ4 — LZ4 コーデックを使用します。
• LZ4HC — LZ4HC コーデックを使用します。
• ZSTD — ZSTD コーデックを使用します。

関連項目

• network_zstd_compression_level

​

network_zstd_compression_level

ZSTD の圧縮レベルを調整します。network_compression_method が ZSTD に設定されている場合にのみ使用されます。

設定可能な値:

• 1 から 15 までの正の整数。

​

normalize_function_names

関数名を正規の名称に正規化します

​

number_of_mutations_to_delay

変更済みのテーブルに少なくともその数の未完了のミューテーションがある場合、テーブルのミューテーションを意図的に遅くします。0 - 無効

​

number_of_mutations_to_throw

mutation 対象のテーブルに、その数以上の未完了の mutation がある場合、‘Too many mutations …’ 例外をスローします。0 - 無効

​

odbc_bridge_connection_pool_size

ODBC bridge における各接続設定文字列の接続プールサイズ。

​

odbc_bridge_use_connection_pooling

ODBC bridge で接続プーリングを使用します。false に設定した場合、毎回新しい接続が作成されます。

​

offset

クエリの結果として行を返し始める前に、スキップする行数を設定します。OFFSET 句で設定されたオフセットを調整するもので、これら2つの値は合算されます。

設定可能な値:

• 0 — 行はスキップされません。
• 正の整数。

例

入力テーブル:

CREATE TABLE test (i UInt64) ENGINE = MergeTree() ORDER BY i;
INSERT INTO test SELECT number FROM numbers(500);

クエリ:

SET limit = 5;
SET offset = 7;
SELECT * FROM test LIMIT 10 OFFSET 100;

結果:

┌───i─┐
│ 107 │
│ 108 │
│ 109 │
└─────┘

​

opentelemetry_start_keeper_trace_probability

ZooKeeper リクエストに対してトレースを開始する確率です。親トレースの有無は問いません。

設定可能な値:

• ‘auto’ - opentelemetry_start_trace_probability 設定と同じ
• 0 — トレースは無効
• 0 から 1 — 確率 (例: 1.0 = 常に有効)

​

opentelemetry_start_trace_probability

ClickHouse が実行されるクエリのトレースを開始する確率を設定します (親のトレースコンテキストが渡されない場合) 。

設定可能な値:

• 0 — すべての実行クエリのトレースが無効になります (親のトレースコンテキストが渡されない場合) 。
• 範囲 [0..1] の正の浮動小数点数。たとえば、設定値が 0,5 の場合、ClickHouse は平均してクエリの半分でトレースを開始できます。
• 1 — すべての実行クエリのトレースが有効になります。

​

opentelemetry_trace_cpu_scheduling

ワークロードのプリエンプティブCPUスケジューリングに関するOpenTelemetryのスパンを収集します。

​

opentelemetry_trace_processors

プロセッサの OpenTelemetry span を収集します。

​

optimize_aggregation_in_order

MergeTree テーブルにおいて、対応する順序でデータを集計する SELECT クエリでの GROUP BY 最適化を有効にします。

設定可能な値:

• 0 — GROUP BY 最適化は無効です。
• 1 — GROUP BY 最適化は有効です。

関連項目

• GROUP BY optimization

​

optimize_aggregators_of_group_by_keys

SELECT 句内の GROUP BY キーに対する min/max/any/anyLast 集約関数を省略します

​

optimize_and_compare_chain

フィルタリング性能を高めるため、AND チェーン内の定数比較を補完します。<、<=、>、>=、= の各演算子と、その組み合わせをサポートします。たとえば、(a < b) AND (b < c) AND (c < 5) は (a < b) AND (b < c) AND (c < 5) AND (b < 5) AND (a < 5) に展開されます。

​

optimize_append_index

索引条件を追加するために、制約を使用します。デフォルトは false です。

設定可能な値:

• true, false

​

optimize_arithmetic_operations_in_aggregate_functions

算術演算を集約関数の外で行います

​

optimize_const_name_size

大きな定数をスカラーに置き換え、その名前としてハッシュを使用します (サイズは名前の長さで推定されます) 。

設定可能な値:

• 正の整数 - 名前の最大長、
• 0 — 常に、
• 負の整数 - 適用しない。

​

optimize_count_from_files

さまざまな入力フォーマットのファイルに対する行数カウントの最適化を有効または無効にします。これは、テーブル関数/エンジン file/s3/url/hdfs/azureBlobStorage に適用されます。

設定可能な値:

• 0 — 最適化は無効です。
• 1 — 最適化は有効です。

​

optimize_dictget_tuple_element

不要な Dictionary 属性の取得を避けるため、tupleElement(dictGet('dict', ('a', 'b', 'c'), key), 2) を dictGet('dict', 'b', key) に書き換えます。位置指定アクセス (.1、.2、…) と名前付きアクセス (.b) をサポートしており、デフォルト引数が定数タプル、または定数のみからなる tuple(...) の場合は dictGetOrDefault にも適用されます。

​

optimize_distinct_in_order

DISTINCT で指定したカラムの一部がソート順のプレフィックスになっている場合に、DISTINCT の最適化を有効にします。たとえば、MergeTree のソートキーや ORDER BY ステートメントのプレフィックスです。

​

optimize_distributed_group_by_sharding_key

イニシエーターサーバーでの高コストな集約を回避することで、GROUP BY sharding_key クエリを最適化します (これにより、イニシエーターサーバーでの当該クエリのメモリ使用量も削減されます) 。

以下の種類のクエリがサポートされています (これらの任意の組み合わせを含む) :

• SELECT DISTINCT [..., ]sharding_key[, ...] FROM dist
• SELECT ... FROM dist GROUP BY sharding_key[, ...]
• SELECT ... FROM dist GROUP BY sharding_key[, ...] ORDER BY x
• SELECT ... FROM dist GROUP BY sharding_key[, ...] LIMIT 1
• SELECT ... FROM dist GROUP BY sharding_key[, ...] LIMIT 1 BY x

以下の種類のクエリはサポートされていません (これらの一部は今後サポートされる可能性があります) :

• SELECT ... GROUP BY sharding_key[, ...] WITH TOTALS
• SELECT ... GROUP BY sharding_key[, ...] WITH ROLLUP
• SELECT ... GROUP BY sharding_key[, ...] WITH CUBE
• SELECT ... GROUP BY sharding_key[, ...] SETTINGS extremes=1

設定可能な値:

• 0 — 無効。
• 1 — 有効。

関連項目:

• distributed_group_by_no_merge
• distributed_push_down_limit
• optimize_skip_unused_shards

現時点では optimize_skip_unused_shards が必要です。これは、将来的にこの設定がデフォルトで有効になる可能性がある一方で、データが Distributed テーブル経由で挿入されている場合、つまり sharding_key に従ってデータが分散されている場合にのみ正しく動作するためです。

​

optimize_dry_run_check_part

有効にすると、OPTIMIZE ... DRY RUN は checkDataPart を使用して、結果として生成されるマージ済みパートを検証します。チェックに失敗した場合は、例外がスローされます。

​

optimize_empty_string_comparisons

col = '' や '' = col のような式は empty(col) に、col != '' や '' != col は notEmpty(col) に変換されます。 ただし、col が String または FixedString 型の場合に限ります。

​

optimize_extract_common_expressions

WHERE、PREWHERE、ON、HAVING、QUALIFY の各式において、論理和から共通式を抽出できるようにします。(A AND B) OR (A AND C) のような論理式は A AND (B OR C) に書き換えられるため、次の最適化に役立つ可能性があります。

• 単純なフィルタ式でのインデックスの活用
• CROSS JOIN から INNER JOIN への最適化

​

optimize_functions_to_subcolumns

一部の関数をサブカラムの読み取りに変換する最適化を有効または無効にします。これにより、読み取るデータ量を削減できます。

以下の関数を変換できます:

• length を、size0 サブカラムを読み取る形に変換。
• empty を、size0 サブカラムを読み取る形に変換。
• notEmpty を、size0 サブカラムを読み取る形に変換。
• isNull を、null サブカラムを読み取る形に変換。
• isNotNull を、null サブカラムを読み取る形に変換。
• count を、null サブカラムを読み取る形に変換。
• mapKeys を、keys サブカラムを読み取る形に変換。
• mapValues を、values サブカラムを読み取る形に変換。

設定可能な値:

• 0 — 最適化は無効です。
• 1 — 最適化は有効です。

​

optimize_group_by_constant_keys

ブロック内のすべてのキーが定数の場合に GROUP BY を最適化します

​

optimize_group_by_function_keys

GROUP BY 句内の他のキーに対する関数を削除します

​

optimize_if_chain_to_multiif

if(cond1, then1, if(cond2, …)) の連鎖を multiIf に置き換えます。現時点では、数値型に対しては有効ではありません。

​

optimize_if_transform_strings_to_enum

If と Transform の String 型のargumentを enum に置き換えます。分散クエリで整合性のない変更が生じて失敗する可能性があるため、デフォルトでは無効になっています。

​

optimize_injective_functions_in_group_by

GROUP BY 句内の単射関数をその引数に置き換えます

​

optimize_injective_functions_in_limit_by

LIMIT BY 句内の単射関数を、その引数に置き換えます。

例: LIMIT 5 BY toString(x) は LIMIT 5 BY x になります。

​

optimize_injective_functions_inside_uniq

uniq*() 関数内の単項の単射関数を削除します。

​

optimize_inverse_dictionary_lookup

事前計算されたキー候補の集合に対してより高速なルックアップを行うことで、逆引きの Dictionary ルックアップを繰り返し実行するのを防ぎます。

​

optimize_limit_by_function_keys

LIMIT BY 句で、他のキーの関数となっているキーを削除します。

例: LIMIT 5 BY x, f(x) は LIMIT 5 BY x になります。

​

optimize_limit_by_in_order

<cols> が (順不同で) テーブルのソートキーのプレフィックスを構成する場合、または WHERE col = const によって先頭のカラムが固定されてそうなる場合に、SELECT ... LIMIT N BY <cols> クエリを最適化します。これを有効にすると、データはプライマリキー順に読み取られるため、BY カラムの値が等しい行は各ストリーム内で隣接して到着します。データが単一のソート済みストリームで到着する場合、LIMIT BY はストリーミングモードでこれをフィルタリングするため、メモリ使用量は O(1) で済み、BY カラムの異なる組み合わせごとにハッシュテーブルを構築する必要がありません。ソート済みデータが複数のストリームで到着し、同じ BY の値が複数のストリームに現れる可能性がある場合は、まず各ストリームをストリーミングモードでグループごとに最大 LIMIT + OFFSET 行まで事前フィルタリングし、その後ストリームを結合して、最後にハッシュベースの LIMIT BY で複数ストリームにまたがるグループを重複排除します。この最後の処理では、依然として BY カラムの異なる組み合わせごとにエントリを保持しますが、処理するのは事前フィルタリング済みの行だけです。

​

optimize_min_equality_disjunction_chain_length

式 expr = x1 OR ... expr = xN を最適化するために必要な最小長

​

optimize_min_inequality_conjunction_chain_length

式 expr <> x1 AND ... expr <> xN を最適化するための最小長

​

optimize_move_to_prewhere

SELECT クエリにおける PREWHERE の自動最適化を有効または無効にします。

*MergeTree テーブルでのみ有効です。

設定可能な値:

• 0 — PREWHERE の自動最適化は無効です。
• 1 — PREWHERE の自動最適化は有効です。

​

optimize_move_to_prewhere_if_final

FINAL 修飾子を使用する SELECT クエリで、自動 PREWHERE 最適化を有効または無効にします。

*MergeTree テーブルでのみ動作します。

設定可能な値:

• 0 — FINAL 修飾子を使用する SELECT クエリでの自動 PREWHERE 最適化は無効です。
• 1 — FINAL 修飾子を使用する SELECT クエリでの自動 PREWHERE 最適化は有効です。

関連項目

• optimize_move_to_prewhere 設定

​

optimize_multiif_to_if

条件が1つしかない ‘multiIf’ を ‘if’ に置き換えます。

​

optimize_normalize_count_variants

意味的に count() と等価な集約関数を count() に書き換えます。

​

optimize_on_insert

INSERT 前のデータ変換を有効または無効にします。これは、テーブルエンジンに応じて、この block に対して merge が実行された場合と同様です。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

例

有効時と無効時の違い:

クエリ:

SET optimize_on_insert = 1;

CREATE TABLE test1 (`FirstTable` UInt32) ENGINE = ReplacingMergeTree ORDER BY FirstTable;

INSERT INTO test1 SELECT number % 2 FROM numbers(5);

SELECT * FROM test1;

SET optimize_on_insert = 0;

CREATE TABLE test2 (`SecondTable` UInt32) ENGINE = ReplacingMergeTree ORDER BY SecondTable;

INSERT INTO test2 SELECT number % 2 FROM numbers(5);

SELECT * FROM test2;

結果:

┌─FirstTable─┐
│          0 │
│          1 │
└────────────┘

┌─SecondTable─┐
│           0 │
│           0 │
│           0 │
│           1 │
│           1 │
└─────────────┘

この設定は、materialized viewの動作にも影響することに注意してください。

​

optimize_or_like_chain

複数の OR LIKE を multiMatchAny に最適化します。この最適化は、場合によっては索引解析を妨げるため、デフォルトで有効にすべきではありません。

​

optimize_prewhere_after_pushdown

後続のクエリプラン最適化によって MergeTree 読み取りステップの上に追加のフィルター (たとえば JOIN を介した述語プッシュダウンやプロジェクションの書き換え) が 追加されることがあるため、その後に 2 回目の PREWHERE 昇格パスを実行します。既存の PREWHERE がすでにある場合、新しいフィルターは別個のフィルターステップのままにはならず、 AND でマージされます。

​

optimize_qbit_distance_function_reads

QBit データ型に対する距離関数を、計算に必要なカラムだけをストレージから読み取る等価な関数に置き換えます。

​

optimize_read_in_order

MergeTree テーブルからデータを読み取る際に、SELECT クエリでの ORDER BY 最適化を有効にします。

設定可能な値:

• 0 — ORDER BY の最適化は無効です。
• 1 — ORDER BY の最適化は有効です。

関連項目

• ORDER BY 句

​

optimize_redundant_functions_in_order_by

引数がすでに ORDER BY に含まれている場合は、ORDER BY から関数を削除します

​

optimize_respect_aliases

true に設定すると、WHERE/GROUP BY/ORDER BY で別名が尊重されます。これにより、パーティションプルーニング、セカンダリ索引、optimize_aggregation_in_order、optimize_read_in_order、optimize_trivial_count の最適化に役立ちます

​

optimize_rewrite_aggregate_function_with_if

引数に if 式を含む集約関数を、論理的に等価な場合は書き換えます。 たとえば、avg(if(cond, col, null)) は avgOrNullIf(cond, col) に書き換えられます。これにより、パフォーマンスが向上する可能性があります。

アナライザ (enable_analyzer = 1) が有効な場合にのみサポートされます。

​

optimize_rewrite_array_exists_to_has

論理的に等価な場合、arrayExists() 関数を has() に書き換えます。たとえば、arrayExists(x -> x = 1, arr) は has(arr, 1) に書き換えられます

​

optimize_rewrite_has_to_in

最初の引数が定数配列の場合、has 関数を IN に書き換えます。たとえば、has([1, 2, 3], x) は、定数配列ではパフォーマンス向上のため x IN [1, 2, 3] に書き換えることができます

​

optimize_rewrite_like_perfect_affix

完全なプレフィックスまたは接尾辞を含む LIKE 式 (例: col LIKE 'ClickHouse%') を、startsWith または endsWith 関数 (例: startsWith(col, 'ClickHouse')) に書き換えます。

​

optimize_rewrite_regexp_functions

正規表現関連の関数を、よりシンプルで効率的な形式に書き換えます

​

optimize_rewrite_sum_if_to_count_if

論理的に等価な場合、sumIf() および sum(if()) 関数を countIf() 関数に書き換えます

​

optimize_skip_merged_partitions

level > 0 のパートが 1 つだけで、その有効期限 (TTL) が切れていない場合に、OPTIMIZE TABLE … FINAL クエリの最適化を有効または無効にします。

• OPTIMIZE TABLE ... FINAL SETTINGS optimize_skip_merged_partitions=1

デフォルトでは、OPTIMIZE TABLE ... FINAL クエリは、パートが 1 つしかない場合でもそのパートを再書き込みします。

設定可能な値:

• 1 - 最適化を有効にします。
• 0 - 最適化を無効にします。

​

optimize_skip_unused_shards

WHERE/PREWHERE に分片キー条件を含む SELECT クエリについて、未使用の分片のスキップを有効または無効にします。また、分散クエリに関連する最適化 (例: 分片キーによる集約) も有効にします。

データが分片キーに従って分散されていることを前提としています。そうでない場合、クエリは不正確な結果を返します。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

optimize_skip_unused_shards_limit

分片キーの値の数の上限です。この上限に達すると、optimize_skip_unused_shards は無効になります。

値が多すぎると処理にかなりのコストがかかる可能性がある一方で、その効果は疑わしい場合があります。IN (...) に非常に多くの値が含まれていると、結局のところクエリはすべての分片に送信される可能性が高いためです。

​

optimize_skip_unused_shards_nesting

分散クエリのネストレベルに応じて optimize_skip_unused_shards の動作を制御します (この設定を有効にするには、optimize_skip_unused_shards も有効である必要があります) 。これは、ある Distributed table が別の Distributed table を参照する場合に該当します。

設定可能な値:

• 0 — 無効。optimize_skip_unused_shards は常に動作します。
• 1 — optimize_skip_unused_shards を最初のレベルでのみ有効にします。
• 2 — optimize_skip_unused_shards を第 2 レベルまで有効にします。

​

optimize_skip_unused_shards_rewrite_in

リモート分片向けのクエリ内の IN を書き換え、その分片に属さない値を除外します (optimize_skip_unused_shards が必要です) 。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

optimize_sorting_by_input_stream_properties

入力ストリームの並び順の特性に基づいてソートを最適化します

​

optimize_substitute_columns

カラムの置換には制約を使用します。既定値はfalseです。

設定可能な値:

• true, false

​

optimize_syntax_fuse_functions

同一の引数を持つ集約関数を統合する最適化を有効にします。同一の引数を持つ sum、count、avg のうち、少なくとも 2 つを含むクエリは sumCount に書き換えられます。

設定可能な値:

• 0 — 同一の引数を持つ関数は統合されません。
• 1 — 同一の引数を持つ関数は統合されます。

例

クエリ:

CREATE TABLE fuse_tbl(a Int8, b Int8) Engine = Log;
SET optimize_syntax_fuse_functions = 1;
EXPLAIN SYNTAX run_query_tree_passes = 1 SELECT sum(a), sum(b), count(b), avg(b) from fuse_tbl FORMAT TSV;

結果:

SELECT
    sum(__table1.a) AS `sum(a)`,
    tupleElement(sumCount(__table1.b), 1) AS `sum(b)`,
    tupleElement(sumCount(__table1.b), 2) AS `count(b)`,
    divide(tupleElement(sumCount(__table1.b), 1), toFloat64(tupleElement(sumCount(__table1.b), 2))) AS `avg(b)`
FROM default.fuse_tbl AS __table1

​

optimize_throw_if_noop

OPTIMIZE クエリでマージが実行されなかった場合に、例外をスローするかどうかを有効または無効にします。

デフォルトでは、OPTIMIZE は何も実行しなかった場合でも正常に成功を返します。この設定を使うと、こうした状況を区別し、その理由を例外メッセージで確認できます。

設定可能な値:

• 1 — 例外のスローが有効です。
• 0 — 例外のスローは無効です。

​

optimize_time_filter_with_preimage

関数を変換不要な等価比較に書き換えることで、Date および DateTime の述語を最適化します (例: toYear(col) = 2023 -> col >= '2023-01-01' AND col <= '2023-12-31')

​

optimize_trivial_approximate_count_query

この種の推定に対応するストレージ (たとえば EmbeddedRocksDB) では、単純な count の最適化に近似値を使用します。

設定可能な値:

• 0 — 最適化は無効です。
  • 1 — 最適化は有効です。

​

optimize_trivial_count_query

MergeTree のメタデータを利用して、自明なクエリ SELECT count() FROM table を最適化する機能を有効または無効にします。行レベルセキュリティを使用する必要がある場合は、この設定を無効にしてください。

設定可能な値:

• 0 — 最適化は無効です。
  • 1 — 最適化は有効です。

関連項目:

• optimize_functions_to_subcolumns

​

optimize_trivial_group_by_limit_query

max_rows_to_group_by = n + offset および group_by_overflow_mode = 'any' を設定することで、単純なクエリ SELECT key_expr FROM table GROUP BY key_expr LIMIT n の最適化を有効または無効にします (SELECT リストに集約関数がなく、HAVING/ORDER BY/LIMIT BY/ウィンドウ句がなく、GROUP BY 修飾子もない場合) 。n + offset 個の異なるキーが生成された時点で、集約は停止します。

この最適化は、ユーザーが group_by_overflow_mode を明示的に any 以外の値に設定している場合 (明示した throw/break の動作を維持するため) 、およびユーザーがすでにより厳しい max_rows_to_group_by を設定している場合 (この最適化では何も変わらないため) には適用されません。

設定可能な値:

• 0 — 最適化は無効です。
  • 1 — 最適化は有効です。

​

optimize_trivial_insert_select

単純な ‘INSERT INTO table SELECT … FROM TABLES’ クエリを最適化

​

optimize_truncate_order_by_after_group_by_keys

ORDER BY のプレフィックスにすべての GROUP BY キーが含まれた時点で、末尾の ORDER BY 要素を削除します。

​

optimize_uniq_to_count

サブクエリに DISTINCT 句または GROUP BY 句がある場合、uniq およびそのバリアント (uniqUpTo を除く) を count に書き換えます。

​

optimize_use_implicit_projections

SELECTクエリの実行時に、暗黙的なプロジェクションを自動的に選択します

​

optimize_use_projection_filtering

SELECT クエリの実行にプロジェクションが選択されていない場合でも、プロジェクションを使用して part の範囲をフィルタリングできるようにします。

​

optimize_use_projections

別名: allow_experimental_projection_optimization

SELECT クエリの処理時に、プロジェクション最適化を有効または無効にします。

設定可能な値:

• 0 — プロジェクション最適化は無効です。
• 1 — プロジェクション最適化は有効です。

​

optimize_using_constraints

クエリ最適化には、制約を使用します。デフォルトはfalseです。

設定可能な値:

• true, false

​

os_threads_nice_value_materialized_view

materialized view のスレッドに対する Linux の nice 値です。値が低いほど CPU 優先度が高くなります。

CAP_SYS_NICE capability が必要です。これがない場合は no-op になります。

設定可能な値: -20 ～ 19。

​

os_threads_nice_value_query

別名: os_thread_priority

クエリ処理スレッドの Linux の nice 値です。値が小さいほど、CPU の優先度は高くなります。

CAP_SYS_NICE capability が必要です。ない場合は no-op になります。

設定可能な値: -20 から 19。

​

page_cache_block_size

ユーザー空間のページキャッシュに保存するファイル chunk のサイズを、バイト単位で指定します。cache を経由するすべての読み取りは、このサイズの倍数に切り上げられます。

この設定はクエリごとに調整できますが、block サイズが異なる cache エントリは再利用できません。この設定を変更すると、既存の cache エントリは実質的に無効化されます。

1 MiB のような大きな値は高スループットのクエリに適しており、64 KiB のような小さな値は低レイテンシのポイントクエリに適しています。

​

page_cache_inject_eviction

ユーザー空間ページキャッシュは、ときどき一部のページをランダムに無効化します。テスト用途を想定しています。

​

page_cache_lookahead_blocks

ユーザー空間ページキャッシュでキャッシュミスが発生した場合、下位ストレージから、キャッシュにも存在しない連続するブロックを一度に最大この数まで読み込みます。各ブロックのサイズは page_cache_block_size バイトです。

値を大きくすると高スループットのクエリに適しており、低レイテンシのポイントクエリでは先読みを行わないほうが適しています。

​

page_cache_max_coalesced_bytes

readBigAt がユーザー空間ページキャッシュを拡充する際、連続する cache ミスは基盤ストレージからの単一の読み取りにまとめられます。この設定は、その1回の結合読み取りのサイズをバイト単位で制限します。ミスの連続区間がこれより長い場合は、複数の読み取りに分割されます。これにより、並列なコールドリード時に一時バッファの一時的なメモリ使用量を抑えられます。

値を大きくすると、オブジェクトストレージに対するコールドスキャン時の HTTP リクエスト数が減少し、値を小さくすると、一時的なメモリ使用量のピークが低減されます。

​

paimon_target_snapshot_id

Paimon のインクリメンタルモードにおける、クエリレベルの対象スナップショット読み取りです。>0 の場合、リーダーはコミット済みのウォーターマークを進めることなく、 指定された snapshot_id の差分のみを取得します。 デフォルト: -1 (無効)

​

parallel_distributed_insert_select

並列分散 INSERT ... SELECT クエリを有効にします。

INSERT INTO distributed_table_a SELECT ... FROM distributed_table_b クエリを実行し、両方のテーブルが同じクラスターを使用していて、かつ両方のテーブルが レプリケーション対応 または非レプリケートである場合、このクエリは各分片でローカルに処理されます。

設定可能な値:

• 0 — 無効。
• 1 — SELECT は、Distributed エンジンの基になるテーブルから各分片で実行されます。
• 2 — SELECT は Distributed エンジンの基になるテーブルから、INSERT はその基になるテーブルへ、各分片で実行されます。

v25.4 以降、ReplicatedMergeTree または SharedMergeTree をソースとする INSERT ... SELECT も、レプリカ間で並列化できるようになりました。有効にするには:

• parallel_distributed_insert_select = 2
• enable_parallel_replicas = 1

​

parallel_hash_join_threshold

ハッシュベースのjoin algorithmが適用される場合、このしきい値は hash と parallel_hash のどちらを使用するかを判断するのに役立ちます (右側のテーブルサイズを見積もれる場合のみ) 。 前者は、右側のテーブルサイズがこのしきい値を下回ることがわかっている場合に使用されます。

​

parallel_non_joined_rows_processing

RIGHT JOIN および FULL JOIN の実行中に、右側のテーブルの非結合行を複数のスレッドで並列に処理できるようにします。 大きなテーブルで parallel_hash ハッシュ結合アルゴリズムを使用する場合、これにより非結合フェーズを高速化できることがあります。 無効にすると、非結合行は単一のスレッドで処理されます。

​

parallel_replica_offset

これは内部設定であり、直接使用すべきではありません。また、「並列レプリカ」モードの実装詳細を表すものです。この設定は、分散クエリにおいて、並列レプリカの中でクエリ処理に参加するレプリカの索引を示す値として、イニシエーターサーバーによって自動的に設定されます。

​

parallel_replicas_allow_in_with_subquery

true の場合、IN のサブクエリは各フォロワーレプリカで実行されます。

​

parallel_replicas_allow_materialized_views

並列レプリカで materialized view を使用できるようにする

​

parallel_replicas_allow_view_over_mergetree

単純なビューが MergeTree テーブル上にある場合、並列レプリカでビューの内側のクエリではなく外側のクエリを実行できるようにし、ノード間の並列化を向上させます。これは、すべての分岐がそれぞれ異なる MergeTree テーブルを読み取る UNION ALL ビューにも適用されます。

​

parallel_replicas_connect_timeout_ms

並列レプリカによるクエリ実行時に、リモートレプリカへの接続に使用されるタイムアウト時間 (ミリ秒) です。タイムアウトした場合、該当するレプリカはクエリ実行に使用されません

​

parallel_replicas_count

これは内部設定であり、直接使用すべきではありません。「並列レプリカ」モードの実装上の詳細を表すものです。この設定は、分散クエリに対して、クエリ処理に参加する並列レプリカ数に応じて、イニシエーターサーバーによって自動的に設定されます。

​

parallel_replicas_custom_key

特定のテーブルに対して、レプリカ間で処理を分割するために使用できる任意の整数式です。 値には任意の整数式を指定できます。

主キーを使用した単純な式が推奨されます。

この設定を、複数のレプリカを持つ単一の分片で構成されるクラスターで使用した場合、それらのレプリカは仮想分片に変換されます。 それ以外の場合は、SAMPLE キーと同様に動作し、各分片の複数のレプリカを使用します。

​

parallel_replicas_custom_key_range_lower

フィルタータイプ range が、カスタム範囲 [parallel_replicas_custom_key_range_lower, INT_MAX] に基づいて処理をレプリカ間で均等に分割できるようにします。

parallel_replicas_custom_key_range_upper と組み合わせて使用すると、範囲 [parallel_replicas_custom_key_range_lower, parallel_replicas_custom_key_range_upper] に対して、フィルターが処理をレプリカ間で均等に分割できるようになります。

注: この設定によってクエリ処理中に追加のデータがフィルタリングされることはありません。代わりに、並列処理のために範囲フィルターが [0, INT_MAX] を分割する位置が変更されます。

​

parallel_replicas_custom_key_range_upper

フィルタータイプ range が、カスタム範囲 [0, parallel_replicas_custom_key_range_upper] に基づいて、レプリカ間で処理を均等に分割できるようにします。値を 0 にすると上限は無効になり、カスタムキー式の最大値が設定されます。

parallel_replicas_custom_key_range_lower と組み合わせて使用すると、範囲 [parallel_replicas_custom_key_range_lower, parallel_replicas_custom_key_range_upper] に対して、フィルターがレプリカ間で処理を均等に分割できるようになります。

注: この設定によってクエリ処理中に追加のデータがフィルターされることはありません。代わりに、並列処理のために range フィルターが範囲 [0, INT_MAX] を分割する位置が変更されます

​

parallel_replicas_filter_pushdown

並列レプリカが実行するクエリ部分にフィルターをプッシュダウンできるようにします

​

parallel_replicas_for_cluster_engines

テーブル関数エンジンを対応する -Cluster の代替に置き換えます

​

parallel_replicas_for_non_replicated_merge_tree

true の場合、ClickHouse は非レプリケートの MergeTree テーブルでも並列レプリカアルゴリズムを使用します

​

parallel_replicas_index_analysis_only_on_coordinator

索引解析はレプリカコーディネーターでのみ実行され、他のレプリカではスキップされます。parallel_replicas_local_pla が有効な場合にのみ適用されます

​

parallel_replicas_insert_select_local_pipeline

並列レプリカを使用した分散 INSERT SELECT 時にローカルパイプラインを使用します

​

parallel_replicas_local_plan

ローカルレプリカ用のローカルプランを構築します

​

parallel_replicas_mark_segment_size

パーツは、並列読み取りのためにレプリカ間へ分散できるよう、仮想的にセグメントに分割されます。この設定は、それらのセグメントのサイズを制御します。何をしているのかを完全に理解している場合を除き、変更は推奨されません。値は [128; 16384] の範囲である必要があります

​

parallel_replicas_min_number_of_rows_per_replica

クエリで使用するレプリカ数を、 (読み取ると推定される行数 / min_number_of_rows_per_replica) の範囲に制限します。最大値は引き続き max_parallel_replicas によって制限されます

​

parallel_replicas_mode

並列レプリカでカスタムキーとともに使用するフィルターの種類。default - カスタムキーに対してモジュロ演算を使用します。range - カスタムキーの値型で取り得るすべての値を使って、カスタムキーに範囲フィルターを適用します。

​

parallel_replicas_only_with_analyzer

並列レプリカを使用するには、アナライザを有効にする必要があります。アナライザが無効な場合は、レプリカからの並列読み取りが有効になっていても、クエリはローカル実行にフォールバックします。アナライザを有効にせずに並列レプリカを使用することはサポートされていません

​

parallel_replicas_prefer_local_join

true で、JOIN を並列レプリカアルゴリズムで実行でき、JOIN の右側のすべてのストレージが *MergeTree である場合は、GLOBAL JOIN ではなくローカル JOIN が使用されます。

​

parallel_replicas_prefer_local_replica

有効な場合 (デフォルト) 、並列読み取りに使用されるレプリカの集合には常にローカルレプリカが含まれます。 無効な場合、ローカルレプリカは優先されず、レプリカはロードバランシングアルゴリズムのみに基づいて選択されます。 これにより、max_parallel_replicas = 1 を指定したクエリを別のホストに振り向けることができ、多数の短いクエリがクラスター全体に分散される場合の cache の局所性を向上できます。

​

parallel_replicas_support_projection

並列レプリカでプロジェクションの最適化を利用できます。parallel_replicas_local_plan が有効で、aggregation_in_order が無効な場合にのみ有効です。

​

parallel_view_processing

アタッチされたビューへのプッシュを、逐次ではなく同時に実行できるようにします。

​

parallelize_output_from_storages

ストレージからの読み取りステップの出力を並列化します。可能な場合は、ストレージから読み取った直後のクエリ処理を並列化できます。

​

parsedatetime_e_requires_space_padding

関数 parseDateTime のフォーマッタ %e は、1 桁の日付は空白で埋められていることを想定しています。たとえば、' 2' は受け付けられますが、'2' はエラーになります。

​

parsedatetime_parse_without_leading_zeros

関数 ‘parseDateTime’ では、フォーマッタ ‘%c’、‘%l’、‘%k’ により、先頭にゼロのない月や時をパースできます。

​

partial_merge_join_left_table_buffer_bytes

0 以外の場合、partial merge join の左側テーブルについて、左テーブルのブロックをより大きな単位にまとめます。joining thread ごとに、指定したメモリ量の最大 2 倍を使用します。

​

partial_merge_join_rows_in_right_blocks

JOIN クエリで partial merge join アルゴリズムを使用する際の、右側の結合データブロックのサイズを制限します。

ClickHouse server:

1. 右側の結合データを、指定した行数以下のブロックに分割します。
2. 各ブロックに最小値と最大値に基づく索引を作成します。
3. 可能であれば、準備したブロックをディスクにアンロードします。

設定可能な値:

• 任意の正の整数。推奨値の範囲: [1000, 100000]。

​

partial_result_on_first_cancel

キャンセル後に、クエリが部分的な結果を返せるようにします。

​

parts_to_delay_insert

宛先テーブルの1つのパーティションに少なくともこの数のアクティブなパーツがある場合、テーブルへの insert を意図的に遅くします。

​

parts_to_throw_insert

宛先テーブルの1つのパーティション内でアクティブなパーツ数がこの値を超えると、‘パーツが多すぎる …’ 例外をスローします。

​

per_part_index_stats

パートごとの索引統計をログに記録します

​

poll_interval

サーバーのクエリ待機ループを、指定した秒数だけブロックします。

​

polyglot_dialect

polyglot トランスパイラの入力元のSQL方言 (例: ‘sqlite’、‘mysql’、‘postgresql’、‘snowflake’、‘duckdb’) 。

​

postgresql_connection_attempt_timeout

PostgreSQL エンドポイントへの 1 回の接続試行における接続タイムアウトを、秒単位で指定します。 この値は、接続 URL の connect_timeout パラメータとして渡されます。

​

postgresql_connection_pool_auto_close_connection

接続をプールに返却する前に、その接続を閉じます。

​

postgresql_connection_pool_retries

PostgreSQL テーブルエンジンおよびデータベースエンジンの接続プールでの push/pop の再試行回数。

​

postgresql_connection_pool_size

PostgreSQL table engineおよびデータベースエンジンの接続プールサイズ。

​

postgresql_connection_pool_wait_timeout

PostgreSQL テーブルエンジンおよびデータベースエンジンで、接続プールが空の場合の push/pop のタイムアウトを設定します。デフォルトでは、プールが空でも待機します。

​

postgresql_fault_injection_probability

内部の (レプリケーション用) PostgreSQLクエリを失敗させるおおよその確率です。有効な値の範囲は [0.0f, 1.0f] です

​

predicate_statistics_sample_rate

述語の選択性統計を system.predicate_statistics_log に収集します。N > 0 に設定すると、クエリ ID に基づいてクエリのおよそ 1/N がサンプリングされます。0 は無効を意味します。

​

prefer_column_name_to_alias

クエリの式や句で、別名ではなく元のカラム名を使うかどうかを有効または無効にします。特に、別名がカラム名と同じ場合に重要です。Expression Aliases を参照してください。この設定を有効にすると、ClickHouse の別名構文ルールが、他の多くのデータベースエンジンとの互換性をより高められます。

設定可能な値:

• 0 — カラム名は別名に置き換えられます。
• 1 — カラム名は別名に置き換えられません。

例

有効時と無効時の違い:

クエリ:

SET prefer_column_name_to_alias = 0;
SELECT avg(number) AS number, max(number) FROM numbers(10);

結果:

Received exception from server (version 21.5.1):
Code: 184. DB::Exception: Received from localhost:9000. DB::Exception: Aggregate function avg(number) is found inside another aggregate function in query: While processing avg(number) AS number.

クエリ:

SET prefer_column_name_to_alias = 1;
SELECT avg(number) AS number, max(number) FROM numbers(10);

結果:

┌─number─┬─max(number)─┐
│    4.5 │           9 │
└────────┴─────────────┘

​

prefer_external_sort_block_bytes

外部ソートではブロックの最大バイト数を優先し、マージ時のメモリ使用量を削減します。

​

prefer_global_in_and_join

IN/JOIN 演算子を GLOBAL IN/GLOBAL JOIN に置き換えるようにします。

設定可能な値:

• 0 — 無効。IN/JOIN 演算子は GLOBAL IN/GLOBAL JOIN に置き換えられません。
• 1 — 有効。IN/JOIN 演算子は GLOBAL IN/GLOBAL JOIN に置き換えられます。

使用方法

SET distributed_product_mode=global を使用すると、分散テーブルに対するクエリの動作は変更できますが、ローカルテーブルや外部リソース上のテーブルには適していません。そこで prefer_global_in_and_join 設定が役立ちます。

たとえば、ローカルテーブルを持つクエリ処理ノードがあり、これらは分散には適していないとします。その場合、分散処理時に GLOBAL キーワード、つまり GLOBAL IN/GLOBAL JOIN を使って、それらのデータをその場で分散させる必要があります。

prefer_global_in_and_join のもう 1 つのユースケースは、外部エンジンで作成されたテーブルにアクセスする場合です。この設定を使うと、そのようなテーブルを JOIN するときの外部ソースへの呼び出し回数を削減できます。クエリごとに 1 回だけで済みます。

関連項目:

• GLOBAL IN/GLOBAL JOIN の使い方について詳しくは、Distributed subqueries を参照してください

​

prefer_localhost_replica

分散クエリの処理時に、localhost のレプリカを優先的に使用するかどうかを有効/無効にします。

設定可能な値:

• 1 — localhost のレプリカが存在する場合、ClickHouse は常にそのレプリカにクエリを送信します。
• 0 — ClickHouse は、load_balancing 設定で指定された負荷分散戦略を使用します。

parallel_replicas_custom_key を使用せずに max_parallel_replicas を使う場合は、この設定を無効にしてください。 parallel_replicas_custom_key が設定されている場合は、複数の分片それぞれに複数のレプリカがあるクラスターで使用しているときにのみ、この設定を無効にしてください。 単一の分片に複数のレプリカがあるクラスターで使用している場合、この設定を無効にすると悪影響が生じます。

​

prefer_warmed_unmerged_parts_seconds

ClickHouse Cloud でのみ効果があります。マージ済みパーツの経過時間がこの秒数未満で、かつ事前ウォームされていない場合 (cache_populated_by_fetch を参照) 、その元となるすべてのパーツが利用可能で事前ウォームされていれば、SELECT クエリは代わりにそれらのパーツから読み取ります。Replicated-/SharedMergeTree でのみ有効です。なお、これは CacheWarmer がそのパーツを処理したかどうかだけを確認します。別の要因でそのパーツが cache にフェッチされていたとしても、CacheWarmer が処理するまではコールドと見なされます。逆に、いったんウォームされていれば、その後 cache から追い出されても、引き続きウォーム済みと見なされます。

​

preferred_block_size_bytes

この設定は、クエリ処理におけるデータブロックのサイズを調整するもので、より大まかな max_block_size 設定をさらに細かく調整するためのものです。カラムのサイズが大きく、max_block_size 行ではブロックサイズが指定したバイト数を超える可能性が高い場合、CPU cache の局所性を高めるためにブロックサイズが小さくされます。

​

preferred_max_column_in_block_size_bytes

読み取り時のブロック内のカラムの最大サイズの上限です。キャッシュミスの回数を減らすのに役立ちます。L2 cache のサイズに近い値にする必要があります。

​

preferred_optimize_projection_name

空でない文字列が設定されている場合、ClickHouse はクエリで指定されたプロジェクションを適用しようとします。

設定可能な値:

• string: 優先するプロジェクションの名前

​

prefetch_buffer_size

ファイルシステムから読み取る際のプリフェッチバッファの最大サイズです。

​

print_pretty_type_names

DESCRIBE クエリおよび toTypeName() 関数で、深くネストされた型名をインデント付きで見やすく表示できるようにします。

例:

CREATE TABLE test (a Tuple(b String, c Tuple(d Nullable(UInt64), e Array(UInt32), f Array(Tuple(g String, h Map(String, Array(Tuple(i String, j UInt64))))), k Date), l Nullable(String))) ENGINE=Memory;
DESCRIBE TABLE test FORMAT TSVRaw SETTINGS print_pretty_type_names=1;

a   Tuple(
    b String,
    c Tuple(
        d Nullable(UInt64),
        e Array(UInt32),
        f Array(Tuple(
            g String,
            h Map(
                String,
                Array(Tuple(
                    i String,
                    j UInt64
                ))
            )
        )),
        k Date
    ),
    l Nullable(String)
)

​

優先度

クエリの優先度。1 が最も高く、値が大きいほど優先度は低くなります。0 は優先度を使用しないことを示します。

​

promql_database

‘promql’ dialect で使用するデータベース名を指定します。空文字列は現在のデータベースを意味します。

​

promql_evaluation_time

別名: evaluation_time

promql dialect で使用する評価時刻を指定します。auto は現在時刻を表します。

​

promql_table

‘promql’ ダイアレクトで使用される TimeSeries テーブル名を指定します。

​

push_external_roles_in_interserver_queries

クエリの実行中に、クエリの発行元から他のノードへユーザーロールをプッシュすることを有効にします。

​

query_cache_compress_entries

query cache 内のエントリを圧縮します。これにより、query cache のメモリ消費量は抑えられますが、そこへの書き込み / そこからの読み取りは遅くなります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_cache_for_subqueries

有効にすると、サブクエリの結果を query cache に書き込み、そこから読み出せるようになります。これにより、use_query_cache がすべてのサブクエリに伝播されます。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_cache_max_entries

現在のユーザーがquery cacheに保存できるクエリ結果の最大件数です。0 は無制限を意味します。

設定可能な値:

• 0 以上の整数。

​

query_cache_max_size_in_bytes

現在のユーザーがクエリキャッシュに割り当て可能なメモリの最大量 (バイト単位) です。0 は無制限を意味します。

設定可能な値:

• 0 以上の整数。

​

query_cache_min_query_duration

クエリの結果を query cache に保存するために必要な、クエリの最小実行時間 (ミリ秒単位) 。

設定可能な値:

• 0 以上の整数。

​

query_cache_min_query_runs

結果がクエリキャッシュに保存されるまでに、SELECTクエリを実行する必要がある最小回数です。

設定可能な値:

• 0 以上の整数。

​

query_cache_nondeterministic_function_handling

rand() や now() のような非決定論的関数を含む SELECT クエリを、クエリキャッシュ がどのように扱うかを制御します。

設定可能な値:

• 'throw' - 例外をスローし、クエリ結果をキャッシュしません。
• 'save' - クエリ結果をキャッシュします。
• 'ignore' - クエリ結果をキャッシュせず、例外もスローしません。

​

query_cache_share_between_users

有効にすると、クエリキャッシュ にキャッシュされた SELECT クエリの結果を、他のユーザーも読み取れるようになります。 セキュリティ上の理由から、この設定を有効にすることは推奨されません。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_cache_squash_partial_results

部分的な結果ブロックを、max_block_size サイズのブロックにまとめます。クエリキャッシュ への insert のパフォーマンスは低下しますが、cache エントリの圧縮効率が向上します (query_cache_compress-entries を参照) 。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_cache_system_table_handling

クエリキャッシュがシステムテーブル、つまりデータベース system.* および information_schema.* 内のテーブルに対する SELECT クエリをどのように扱うかを制御します。

設定可能な値:

• 'throw' - 例外をスローし、クエリ結果をキャッシュしません。
• 'save' - クエリ結果をキャッシュします。
• 'ignore' - クエリ結果をキャッシュせず、例外もスローしません。

​

query_cache_tag

query cache のエントリのラベルとして機能する文字列です。 同じクエリでもタグが異なれば、query cache では別のものとして扱われます。

設定可能な値:

• 任意の文字列

​

query_cache_ttl

この秒数を過ぎると、query cache 内のエントリは古いものと見なされます。

設定可能な値:

• 0 以上の整数。

​

query_metric_log_interval

個々のクエリについて query_metric_log を収集する間隔 (ミリ秒) です。

負の値を設定すると、query_metric_log setting の collect_interval_milliseconds の値が使用され、設定されていない場合はデフォルトで 1000 になります。

個別のクエリの収集を無効にするには、query_metric_log_interval を 0 に設定します。

デフォルト値: -1

​

query_plan_aggregation_in_order

in-order 集約に関するクエリプランレベルの最適化を切り替えます。 設定 query_plan_enable_optimizations が 1 の場合にのみ有効です。

これは上級者向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。この設定は将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_convert_any_join_to_semi_or_anti_join

JOIN 後のフィルタが、不一致の行または一致した行に対して常に false と評価される場合に、ANY JOIN を SEMI JOIN または ANTI JOIN に変換できるようにします

​

query_plan_convert_join_to_in

出力カラムが左側のテーブルにのみ関連している場合に、JOIN を IN を使用するサブクエリに変換することを許可します。非 ANY JOIN (たとえば、デフォルトの ALL JOIN) では、誤った結果になる可能性があります。

​

query_plan_convert_outer_join_to_inner_join

JOIN 後のフィルター条件によって常にデフォルト値が除外される場合、OUTER JOIN を INNER JOIN に変換できるようにします

​

query_plan_direct_read_from_text_index

クエリプランで、転置テキスト索引のみを使用した全文検索フィルタリングを実行できるようにします。

​

query_plan_display_internal_aliases

元のクエリで指定された別名ではなく、EXPLAIN PLAN に内部別名 (__table1 など) を表示します。

​

query_plan_enable_multithreading_after_window_functions

並列ストリーム処理を可能にするため、ウィンドウ関数の評価後にマルチスレッドを有効にします

​

query_plan_enable_optimizations

クエリプランレベルのクエリ最適化の有効/無効を切り替えます。

これは上級者向けの設定であり、開発者によるデバッグ用途でのみ使用してください。将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - クエリプランレベルのすべての最適化を無効にする
• 1 - クエリプランレベルの最適化を有効にする (ただし、個々の最適化はそれぞれの設定で無効にできる場合があります)

​

query_plan_execute_functions_after_sorting

ソート処理の後に式を移動するクエリプランレベルの最適化を切り替えます。 query_plan_enable_optimizations が 1 の場合にのみ有効です。

これはエキスパート向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。この設定は将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_filter_push_down

実行プラン内でフィルタを下位に押し下げる、クエリプランレベルの最適化の有効/無効を切り替えます。 この設定は、query_plan_enable_optimizations が 1 の場合にのみ有効です。

これはエキスパート向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。この設定は将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_join_shard_by_pk_ranges

両方のテーブルで、結合キーに PRIMARY KEY のプレフィックスが含まれている場合は、JOIN に分片化を適用します。hash、parallel_hash、full_sorting_merge アルゴリズムでサポートされています。通常、クエリの高速化にはつながりませんが、メモリ消費を抑えられる場合があります。

​

query_plan_join_swap_table

クエリプランで、JOIN のどちら側を build table (inner とも呼ばれ、ハッシュ結合ではハッシュテーブルに挿入される側) にするかを決定します。この設定は、JOIN ON 句を使用する strictness が ALL の JOIN でのみサポートされます。設定可能な値は次のとおりです。

• ‘auto’: planner がどの table を build table として使用するかを決定します。
  • ‘false’: table を入れ替えません (右側の table が build table になります) 。
  • ‘true’: 常に table を入れ替えます (左側の table が build table になります) 。

​

query_plan_lift_up_array_join

実行計画内で ARRAY JOIN を上位に移動する、クエリプランレベルの最適化を切り替えます。 この設定は、query_plan_enable_optimizations が 1 の場合にのみ有効です。

これは上級者向けの設定であり、開発者がデバッグのためにのみ使用すべきです。この設定は、将来後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_lift_up_union

より大きなクエリプランの部分木をユニオン内へ移動して、追加の最適化を可能にするクエリプランレベルの最適化を有効または無効にします。 この設定は query_plan_enable_optimizations が 1 の場合にのみ有効です。

これは上級者向けの設定であり、開発者がデバッグ目的でのみ使用するべきものです。この設定は今後、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_max_limit_for_join_lazy_indexing

JOIN の遅延索引最適化でクエリプランを使用できる最大 LIMIT 値を制御します。0 の場合、制限はありません。

​

query_plan_max_limit_for_lazy_materialization

遅延マテリアライゼーションの最適化でクエリプランを使用できる上限値を制御します。0 の場合、制限はありません。

​

query_plan_max_limit_for_top_k_optimization

minmax スキップ索引と動的しきい値フィルタリングを使用する TopK 最適化で、クエリプランを評価できる limit の最大値を制御します。0 の場合、制限はありません。

​

query_plan_max_optimizations_to_apply

クエリプランに適用する最適化の総数を制限します。設定 query_plan_enable_optimizations を参照してください。 複雑なクエリで最適化に時間がかかりすぎるのを防ぐのに役立ちます。 EXPLAIN PLAN クエリでは、この上限に達すると最適化の適用を停止し、その時点のプランを返します。 通常のクエリ実行では、実際の最適化回数がこの設定値を超えると、例外が発生します。

これはエキスパート向けの設定であり、開発者がデバッグ目的でのみ使用すべきものです。今後、後方互換性のない形で変更されたり、削除されたりする可能性があります。

​

query_plan_max_set_size_for_projection_match

projection matcher が 2 つの Set が等しいかどうかを判定する際に、内容ハッシュを計算して比較する IN 句の Set の最大要素数です。これを超える Set は非一致として扱われ、projection はスキップされます。ゼロを指定すると内容ハッシュの比較は完全に無効になり、IN 句の Set を含むノードでは projection の一致は決して成功しません。

これは aggregate projection matcher (および IN 句の Set を比較する必要がある将来の projection matcher) で使用されます。内容ハッシュの計算量は Set の要素数に対して O(N log N) です。この設定は、クエリまたは projection に多数の IN 句が現れる場合に、プラン時に発生するコストを抑えるためのものです。

​

query_plan_max_step_description_length

EXPLAIN PLAN におけるステップ説明の最大長。

​

query_plan_merge_expressions

連続するフィルターをマージするクエリプランレベルの最適化を有効または無効にします。 設定 query_plan_enable_optimizations が 1 の場合にのみ有効です。

これは上級者向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。この設定は将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_merge_filter_into_join_condition

JOIN 条件へのフィルターのマージを有効にし、CROSS JOIN を INNER に変換します。

​

query_plan_merge_filters

クエリプラン内のフィルターをマージできるようにします。

​

query_plan_min_columns_for_join_lazy_indexing

JOIN で遅延索引最適化を有効にするために必要な、左側のペイロードカラムの最小数を制御します。0 は、この最適化が無効であることを意味します。

​

query_plan_optimize_join_order_algorithm

クエリプランの最適化時に試行する JOIN 順序アルゴリズムを指定します。使用できるアルゴリズムは次のとおりです。

• greedy - 基本的な貪欲アルゴリズムです。高速に動作しますが、最適な JOIN 順序にならない場合があります
• dpsize - 現在は INNER JOIN に対してのみ DPsize アルゴリズムを実装しています。可能なすべての JOIN 順序を考慮して最適なものを見つけますが、多数のテーブルや JOIN 述語を含むクエリでは遅くなる可能性があります
• dphyp - 現在は INNER JOIN に対してのみ DPhyp (Hypergraph Partitioning による動的計画法) アルゴリズムを実装しています。dpsize と同じ探索空間を探索しますが、接続された部分グラフのペアだけを列挙するため、クロス積を考慮しない代わりに、スパースな JOIN グラフでは中間 JOIN の生成が少なくなります 複数のアルゴリズムは、たとえば dphyp,greedy のようにカンマ区切りのリストとして指定できます。これらは順番に試行され、あるアルゴリズムでクエリを処理できない場合 (たとえば OUTER JOIN や非連結のコンポーネントが原因の場合) は、代替として次のものが使用されます。

​

query_plan_optimize_join_order_limit

同じサブクエリ内の JOIN の順序を最適化します。現在のところ、ごく限られたケースでのみサポートされています。 値は、最適化対象となるテーブルの最大数です。

​

query_plan_optimize_join_order_max_searched_plans

query_plan_optimize_join_order_algorithm で指定された次のアルゴリズムにフォールバックするまでに、JOIN 順序オプティマイザが列挙できる部分プランの最大数です。 これにより、クリークやスターのような密な join グラフで探索空間が指数関数的に増大する場合でも、最適化時間を決定論的に (実時間とは無関係に) 制限できます。 制限を無効にするには 0 に設定します。デフォルトの query_plan_optimize_join_order_limit には影響しません。この場合、探索は常にこの上限を大きく下回るためです。

​

query_plan_optimize_join_order_randomize

0 以外の値の場合、JOIN 順序オプティマイザは実際の統計情報の代わりに、ランダムに生成されたカーディナリティと NDV を使用します。 1 に設定すると random seed が生成され、1 より大きい値に設定すると、その値が seed として直接使用されます。 これは、異なる JOIN 順序によって発生するエラーを見つけるためのテストを目的としています。

​

query_plan_optimize_lazy_final

主キーのセットを構築し、それを索引解析に利用することで、ReplacingMergeTree で FINAL を使用した読み取りを最適化します。

​

query_plan_optimize_lazy_materialization

遅延マテリアライゼーションの最適化にクエリプランを使用します。

​

query_plan_optimize_prewhere

サポートされているストレージで、フィルターを PREWHERE 式にプッシュダウンできるようにします

​

query_plan_push_down_limit

実行プラン内で LIMIT を下位に移動する、クエリプランレベルの最適化を切り替えます。 この設定は、query_plan_enable_optimizations が 1 の場合にのみ有効です。

これは上級者向けの設定であり、開発者がデバッグのためにのみ使用すべきです。この設定は将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_push_limit_by_into_sort

ORDER BY ... LIMIT BY クエリに対するクエリプランレベルの最適化を切り替えます。LIMIT BY のカラムが ORDER BY 句のプレフィックスである場合、並列にソートされた各ストリームは、ストリームが 1 つにマージされる前に LIMIT BY を適用するため、最終マージおよび後続のパイプライン段階で処理される行数が減ります。LIMIT BY によって大量の行が除外されるクエリを高速化します。

この設定は、query_plan_enable_optimizations が 1 の場合にのみ有効です。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_read_in_order

クエリプランレベルの read in-order 最適化を有効または無効にします。 設定 query_plan_enable_optimizations が 1 の場合にのみ有効です。

これはエキスパート向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。この設定は、将来後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_read_in_order_through_join

JOIN演算において左側のtableから順序どおりに読み続けます。これは後続の処理で利用できます。

​

query_plan_remove_redundant_distinct

冗長な DISTINCT ステップを削除するクエリプランレベルの最適化の有効/無効を切り替えます。 query_plan_enable_optimizations が 1 の場合にのみ有効です。

これはエキスパート向けの設定であり、開発者がデバッグ目的でのみ使用してください。将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_remove_redundant_sorting

冗長なソートステップ (たとえばサブクエリ内のもの) を削除するクエリプランレベルの最適化を有効または無効にします。 この設定は、query_plan_enable_optimizations が 1 の場合にのみ有効です。

これは上級者向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。この設定は将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_remove_unused_columns

クエリプランの各ステップから未使用のカラム (入力カラムと出力カラムの両方) を削除する、クエリプランレベルの最適化の有効/無効を切り替えます。 この設定は、query_plan_enable_optimizations が 1 の場合にのみ有効です。

これはエキスパート向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。将来的に後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_reuse_storage_ordering_for_window_functions

別名: optimize_read_in_window_order

ウィンドウ関数のソート時にストレージの並び順を利用する、クエリプランレベルの最適化の有効/無効を切り替えます。 設定 query_plan_enable_optimizations が 1 の場合にのみ有効です。

これは上級者向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。この設定は将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_split_filter

これはエキスパート向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。この設定は将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

フィルターを式に分割するクエリプランレベルの最適化を切り替えます。 この設定は、query_plan_enable_optimizations が 1 の場合にのみ有効です。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_text_index_add_hint

クエリプランで、転置テキスト索引から構築されるフィルタリング用のヒント (追加の述語) を追加できるようにします。

​

query_plan_top_k_through_join

ソートキーが join の保持側 (LEFT/RIGHT) のカラムのみを参照している場合に、ORDER BY ... LIMIT n を join の下にプッシュダウンするクエリプランレベルの最適化を切り替えます。これにより、join 前に保持側の入力が生成する必要のある行数が制限されます。 この設定は、query_plan_enable_optimizations が 1 の場合にのみ有効です。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_plan_try_use_vector_search

ベクトル類似度索引の使用を試みるクエリプランレベルの最適化の有効／無効を切り替えます。 設定 query_plan_enable_optimizations が 1 の場合にのみ有効です。

これは上級者向けの設定であり、開発者がデバッグ目的でのみ使用すべきです。この設定は将来、後方互換性のない形で変更されたり、削除されたりする可能性があります。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

query_profiler_cpu_time_period_ns

クエリプロファイラ の CPU クロックタイマーの周期を設定します。このタイマーは CPU 時間のみを計測します。

設定可能な値:

• 正の整数のナノ秒数。

  推奨値:

  • 単一クエリでは 10000000 (1 秒あたり 100 回) ナノ秒以上。
  • クラスター全体のプロファイリングでは 1000000000 (1 秒に 1 回) 。

• タイマーを無効にする場合は 0。

関連項目:

• システムテーブル trace_log

​

query_profiler_real_time_period_ns

クエリプロファイラの実クロックタイマーの周期を設定します。実クロックタイマーは経過時間を計測します。

設定可能な値:

• ナノ秒単位の正の整数。

  推奨値:

  • 単一のクエリでは 10000000 (1 秒あたり 100 回) ナノ秒以下。
  • クラスター全体のプロファイリングでは 1000000000 (1 秒に 1 回) 。

• タイマーを無効にする場合は 0。

関連項目:

• システムテーブル trace_log

Cloud でのデフォルト値: 3000000000.

​

queue_max_wait_ms

同時実行リクエスト数が上限を超えた場合の、リクエストキューでの待機時間です。

​

rabbitmq_max_wait_ms

再試行前に RabbitMQ から読み取る際の待機時間です。

​

read_backoff_max_throughput

読み取りが遅い場合にスレッド数を減らすための設定です。読み取りスループットが1秒あたりこのバイト数を下回る場合に、イベントをカウントします。

​

read_backoff_min_concurrency

読み取りが遅い場合に、スレッドの最小数を維持しようとするための設定です。

​

read_backoff_min_events

読み取りが遅い場合に threads の数を減らすための設定です。threads の数が減らされるまでのイベント数を指定します。

​

read_backoff_min_interval_between_events_ms

読み取りが遅い場合にスレッド数を減らすための設定です。前回のイベントから一定時間以上経過していない場合は、そのイベントを無視します。

​

read_backoff_min_latency_ms

読み取りが遅い場合にスレッド数を減らすための設定です。この時間以上かかった読み取りだけを対象にします。

​

read_from_distributed_cache_if_exists_otherwise_bypass_cache

ClickHouse Cloud でのみ効果があります。read_from_filesystem_cache_if_exists_otherwise_bypass_cache と同じですが、分散キャッシュに対する設定です。

​

read_from_filesystem_cache_if_exists_otherwise_bypass_cache

ファイルシステムキャッシュをパッシブモードで利用できるようにします。既存のキャッシュエントリは利用しますが、新しいエントリはキャッシュに追加しません。負荷の高いアドホッククエリでこの設定を有効にし、短時間のリアルタイムクエリでは無効のままにしておくことで、重いクエリによるキャッシュのスラッシングを防ぎ、システム全体の効率を向上させることができます。

​

read_from_page_cache_if_exists_otherwise_bypass_cache

read_from_filesystem_cache_if_exists_otherwise_bypass_cache と同様に、ユーザー空間の page cache をパッシブモードで使用します。

​

read_in_order_two_level_merge_threshold

主キーの順序でマルチスレッド読み取りを行う際に、preliminary merge ステップを実行するために読み取る最小のパーツ数。

​

read_in_order_use_buffering

主キー順に読み取る際に、マージ前のバッファリングを使用します。これにより、クエリ実行の並列度が向上し

​

read_in_order_use_virtual_row

主キーまたはその単調関数の順序で読み取る際に、仮想行を使用します。複数のパーツをまたいで検索する場合でも、必要なものだけが読み取られるため有用です。

​

read_in_order_use_virtual_row_per_block

read_in_order_use_virtual_row とあわせて有効にすると、各 block の読み取り後に仮想行を出力します (各パーツの先頭時のみではありません) 。 これにより、MergingSortedTransform はソースの優先順位をより頻繁に付け替えられるようになり、下流の filter によって多くの行が破棄され、データがパーツ間で偏って分散している場合に有効です。 なお、これを有効にすると、読み取り時の read_in_order_use_buffering の最適化と preliminary merge (read_in_order_two_level_merge_threshold) は無効になります。

​

read_overflow_mode

制限を超えた場合の動作。

​

read_overflow_mode_leaf

読み込まれたデータ量が leaf 側の制限のいずれかを超えた場合の動作を設定します。

指定可能な値:

• throw: 例外をスローします (デフォルト) 。
• break: クエリの実行を停止し、途中までの結果を返します。

​

read_priority

ローカルfilesystemまたはリモートfilesystemからデータを読み取る際の優先度。ローカルfilesystemでは ‘pread_threadpool’ method、リモートfilesystemでは threadpool method の場合にのみサポートされます。

​

read_through_distributed_cache

ClickHouse Cloud でのみ有効です。分散キャッシュからの読み取りを許可します

​

readonly

0 - read-only の制限はありません。1 - 読み取りリクエストのみ、および明示的に許可された設定の変更のみ。2 - 読み取りリクエストのみ、および ‘readonly’ 設定を除く設定の変更のみ。

​

receive_data_timeout_ms

レプリカから最初のデータパケット、または進捗があることを示す Progress パケットを受信する際の接続タイムアウト

​

receive_timeout

ネットワークからデータを受信する際のタイムアウト時間です。単位は秒です。この時間内に1バイトも受信されなかった場合、例外が発生します。クライアントでこの設定を行うと、サーバー側の対応する接続先でも、そのソケットに対して send_timeout が設定されます。

​

recursive_cte_max_steps_in_type_inference

recursive CTE でカラム型を推論する際の最大反復回数です。カラム型は、非再帰側と再帰側の UNION ALL に対して getLeastSupertype を繰り返し適用し、収束するまで求められます。0 に設定すると型の拡張が無効になり、非再帰部分の型のみが使用されます。

​

regexp_dict_allow_hyperscan

Hyperscanライブラリを使用する regexp_tree Dictionary を有効にします。

​

regexp_dict_flag_case_insensitive

regexp_tree Dictionary に対して、大文字と小文字を区別しないマッチングを使用します。個々の expression では、(?i) および (?-i) を使って上書きできます。

​

regexp_dict_flag_dotall

regexp_tree Dictionary で、’.’ が改行文字にも一致するようにします。

​

regexp_max_matches_per_row

1行あたり、単一の正規表現で許可される最大一致数を設定します。extractAllGroupsHorizontal 関数で貪欲な正規表現を使用する際のメモリ過負荷を防ぐために使用します。

設定可能な値:

• 正の整数。

​

reject_expensive_hyperscan_regexps

hyperscan での評価に高いコストがかかる可能性が高いパターンを拒否します (NFA の状態爆発による)

​

remerge_sort_lowered_memory_bytes_ratio

remerge 後のメモリ使用量がこの比率まで減少しない場合、remerge は無効化されます。

​

remote_filesystem_read_method

リモートファイルシステムからデータを読み取る方法です。指定できる値: read、threadpool。

​

remote_filesystem_read_prefetch

リモートファイルシステムからデータを読み取る際に、プリフェッチを使用するかどうか。

​

remote_fs_read_backoff_max_tries

バックオフ付き読み取りの最大試行回数

​

remote_fs_read_max_backoff_ms

リモートディスクからデータを読み取ろうとする際の最大待機時間

​

remote_read_min_bytes_for_seek

ignore を使った読み取りではなく seek を行うために、リモート読み取り (url、S3) で必要な最小バイト数。

​

rename_files_after_processing

• Type: String

• デフォルト値: 空文字列

この設定では、file テーブル関数で処理したファイルのリネームパターンを指定できます。このオプションを設定すると、file テーブル関数で読み取られたすべてのファイルは、処理が正常に完了した場合に限り、指定したプレースホルダーを含むパターンに従ってリネームされます。

​

プレースホルダー

• %a — 元のファイル名全体 (例: “sample.csv”) 。
• %f — 拡張子を除いた元のファイル名 (例: “sample”) 。
• %e — ドットを含む元の拡張子 (例: “.csv”) 。
• %t — タイムスタンプ (マイクロ秒単位) 。
• %% — パーセント記号 (”%”) 。

​

例

• オプション: --rename_files_after_processing="processed_%f_%t%e"

• クエリ: SELECT * FROM file('sample.csv')

sample.csv の読み取りに成功すると、ファイルは processed_sample_1683473210851438.csv にリネームされます

​

replace_running_query

HTTPインターフェイスを使用する場合は、query_id パラメータを渡せます。これは、クエリ識別子として機能する任意の文字列です。 この時点で、同じユーザーによる同じ query_id のクエリがすでに存在する場合の動作は、replace_running_query パラメータによって決まります。

0 (デフォルト) – 例外をスローします (同じ query_id のクエリがすでに実行中の場合、新しいクエリの実行は許可されません) 。

1 – 古いクエリをキャンセルし、新しいクエリの実行を開始します。

セグメンテーション条件のサジェストを実装する場合は、このパラメータを 1 に設定してください。次の文字が入力された時点で古いクエリがまだ終了していなければ、そのクエリをキャンセルする必要があります。

​

replace_running_query_max_wait_ms

replace_running_query 設定が有効な場合に、同じ query_id を持つ実行中のクエリが終了するまでの待機時間です。

設定可能な値:

• 正の整数。
• 0 — サーバーがすでに同じ query_id を持つクエリを実行している場合、新しいクエリの実行を許可せず、例外を発生させます。

​

replication_wait_for_inactive_replica_timeout

非アクティブなレプリカが ALTER、OPTIMIZE、または TRUNCATE クエリを実行するまで待機する時間 (秒単位) を指定します。

設定可能な値:

• 0 — 待機しません。
• 負の整数 — 無制限に待機します。
• 正の整数 — 待機する秒数です。

​

restore_replace_external_dictionary_source_to_null

復元時に外部 Dictionary ソースを Null に置き換えます。テスト用途に便利です

​

restore_replace_external_engines_to_null

テスト用です。外部接続を開始しないよう、すべての外部エンジンをNullに置き換えます。

​

restore_replace_external_table_functions_to_null

テスト用です。外部接続を開始しないよう、すべての外部テーブル関数を Null に置き換えます。

​

restore_replicated_merge_tree_to_shared_merge_tree

RESTORE 時に、テーブルエンジンを ReplicatedMergeTree から SharedMergeTree に置き換えます。

Cloud でのデフォルト値: 1.

​

result_overflow_mode

Cloud でのデフォルト値: throw

結果のサイズがいずれかの制限を超えた場合の動作を設定します。

設定可能な値:

• throw: 例外をスローします (デフォルト) 。
• break: クエリの実行を停止し、あたかも ソースデータが尽きたかのように部分的な結果を返します。

break の使用は LIMIT の使用に似ています。break は ブロックレベルでのみ実行を中断します。つまり、返される行数は max_result_rows より多くなり、max_block_size の倍数となり、max_threads に依存します。

例

Query

SET max_threads = 3, max_block_size = 3333;
SET max_result_rows = 3334, result_overflow_mode = 'break';

SELECT *
FROM numbers_mt(100000)
FORMAT Null;

Result

6666 rows in set. ...

​

rewrite_count_distinct_if_with_count_distinct_implementation

countDistcintIf を count_distinct_implementation 設定を使って書き換えることを許可します。

設定可能な値:

• true — 許可します。
• false — 許可しません。

​

rewrite_in_to_join

‘x IN subquery’ のような式を JOIN に書き換えます。これは、JOIN の並べ替えによるクエリ全体の最適化に役立つ場合があります。

​

rows_before_aggregation

有効にすると、ClickHouse は rows_before_aggregation 統計の正確な値を返します。これは、集約前に読み取られた行数を表し

​

s3_allow_multipart_copy

S3 でのマルチパートコピーを有効にします。

​

s3_allow_parallel_part_upload

S3 のマルチパートアップロードで複数のスレッドを使用します。これにより、メモリ使用量がわずかに増加する可能性があります

​

s3_check_objects_after_upload

アップロードが正常に完了したことを確認するため、S3 にアップロードされた各オブジェクトに対して HEAD リクエストを実行します

​

s3_connect_timeout_ms

S3ディスクのホストへの接続タイムアウト。

​

s3_create_new_file_on_insert

S3エンジンテーブルで、挿入のたびに新しいファイルを作成するかどうかを制御します。有効にすると、各挿入時に、次のパターンのようなキーを持つ新しい S3 オブジェクトが作成されます。

initial: data.Parquet.gz -> data.1.Parquet.gz -> data.2.Parquet.gz, etc.

設定可能な値:

• 0 — INSERT クエリは新しいファイルを作成します。ファイルがすでに存在し、s3_truncate_on_insert が設定されていない場合は失敗します。
• 1 — s3_truncate_on_insert が設定されていない場合、INSERT クエリは各挿入時に接尾辞を使って新しいファイルを作成します (2 回目以降) 。

詳しくはこちらを参照してください。

​

s3_disable_checksum

S3 にファイルを送信する際にチェックサムを計算しません。これにより、ファイルに対する過剰な処理パスを避けられるため、書き込みが高速になります。これは通常は安全です。というのも、MergeTree テーブルのデータはどのみち ClickHouse 側ですでにチェックサムによって保護されており、HTTPS で S3 にアクセスする場合は、TLS レイヤーがネットワーク転送中の完全性をすでに提供するためです。ただし、S3 で追加のチェックサムを使用すると、多層防御になります。

​

s3_ignore_file_doesnt_exist

特定のキーの読み取り時に、ファイルが存在しない場合はその不在を無視します。

設定可能な値:

• 1 — SELECT は空の結果を返します。
• 0 — SELECT は例外を発生させます。

​

s3_list_object_keys_size

ListObject リクエストで一度に返されるファイルの最大数

​

s3_max_connections

サーバーごとの最大接続数。

​

s3_max_get_burst

1 秒あたりのリクエスト制限に達するまでに同時に発行できるリクエストの最大数。デフォルト値は 0 で、s3_max_get_rps と同じです

​

s3_max_get_rps

スロットリングが適用されるまでの、S3 GET リクエストの1秒あたりの上限数です。0 は無制限を意味します。

​

s3_max_inflight_parts_for_one_file

マルチパートアップロードリクエストで同時にアップロードされるパーツの最大数です。0 は無制限を意味します。

​

s3_max_part_number

S3 アップロードパートの最大パート番号。

​

s3_max_put_burst

1 秒あたりのリクエスト数制限に達するまでに同時発行できるリクエストの最大数。デフォルト値 (0) は s3_max_put_rps と同じです

​

s3_max_put_rps

スロットリングが適用される前の、S3 PUT request の1秒あたりのレート上限です。0 は無制限を意味します。

​

s3_max_single_operation_copy_size

s3 での単一コピー操作の最大サイズです。この設定は、s3_allow_multipart_copy が true の場合にのみ使用されます。

​

s3_max_single_part_upload_size

S3 へのシングルパートアップロードでアップロードできるオブジェクトの最大サイズです。

​

s3_max_single_read_retries

単一のS3読み取り時の最大再試行回数。

​

s3_max_unexpected_write_error_retries

S3への書き込み中に予期しないエラーが発生した場合の、最大再試行回数。

​

s3_max_upload_part_size

S3 へのマルチパートアップロード時にアップロードするパートの最大サイズ。

​

s3_min_upload_part_size

S3 へのマルチパートアップロード時にアップロードするパートの最小サイズ。

​

s3_path_filter_limit

glob リストの代わりにファイルのイテレーションに使用するために、クエリフィルターから抽出できる _path 値の最大数です。 0 は無効を意味します。

​

s3_request_timeout_ms

S3 との間でデータを送受信する際のアイドルタイムアウトです。1 回の TCP 読み取りまたは書き込み呼び出しがこの時間を超えてブロックされると失敗します。

​

s3_skip_empty_files

S3エンジンのテーブルで、空のファイルをスキップするかどうかを設定します。

設定可能な値:

• 0 — 空のファイルが要求されたフォーマットと互換性がない場合、SELECT は例外をスローします。
• 1 — SELECT は空のファイルに対して空の結果を返します。

​

s3_slow_all_threads_after_network_error

true に設定すると、同じバックアップエンドポイントに対して S3 リクエストを実行しているすべてのスレッドは、 いずれか 1 つの S3 リクエストで、ソケットタイムアウトなどの再試行可能なネットワークエラーが発生すると、 その後は処理速度が抑制されます。 false に設定すると、各スレッドは他のスレッドとは独立して S3 リクエストのバックオフを処理します。

​

s3_strict_upload_part_size

S3 へのマルチパートアップロード時にアップロードする各パートの厳密なサイズ (一部の実装では可変サイズのパートをサポートしていません) 。

​

s3_throw_on_zero_files_match

ListObjects リクエストで一致するファイルが 1 つも見つからない場合、エラーをスローします

​

s3_truncate_on_insert

S3 エンジンのテーブルで、INSERT の前に truncate を行うかどうかを有効または無効にします。無効な場合、S3 オブジェクトがすでに存在すると、INSERT を試行した際に例外が発生します。

設定可能な値:

• 0 — INSERT クエリは新しいファイルを作成します。ファイルがすでに存在し、s3_create_new_file_on_insert が設定されていない場合は失敗します。
• 1 — INSERT クエリは、ファイルの既存の内容を新しいデータで置き換えます。

詳しくはこちらを参照してください。

​

s3_upload_part_size_multiply_factor

S3 への1回の書き込みで s3_multiply_parts_count_threshold 個のパーツがアップロードされるたびに、s3_min_upload_part_size にこの係数を掛けます。

​

s3_upload_part_size_multiply_parts_count_threshold

この数のパーツが S3 にアップロードされるたびに、s3_min_upload_part_size は s3_upload_part_size_multiply_factor 倍されます。

​

s3_uri_style

S3 endpoint のスタイルを指定します。設定可能な値: auto、virtual_hosted、path。

​

s3_use_adaptive_timeouts

true に設定すると、すべての S3 リクエストで、最初の 2 回の試行は短めの送受信タイムアウトで実行されます。 false に設定すると、すべての試行が同じタイムアウトで実行されます。

​

s3_validate_request_settings

S3 リクエスト設定の検証を有効にします。 設定可能な値:

• 1 — 設定を検証します。
• 0 — 設定を検証しません。

​

s3queue_default_zookeeper_path

S3QueueエンジンのデフォルトのZooKeeperパスプレフィックス

​

s3queue_enable_logging_to_s3queue_log

system.s3queue_log への書き込みを有効にします。テーブルごとに、テーブル設定でこの値を上書きできます

​

s3queue_keeper_fault_injection_probability

S3Queue に対する Keeper のフォールト挿入確率。

​

s3queue_migrate_old_metadata_to_buckets

S3Queueテーブルの古いメタデータ構造を新しい構造に移行します

​

schema_inference_cache_require_modification_time_for_url

最終更新時刻を検証したうえで、URL に対して cache 内のスキーマを使用します (Last-Modified header を持つ URL 向け)

​

schema_inference_use_cache_for_azure

Azure テーブル関数の使用時に、スキーマ推論で cache を使用します

​

schema_inference_use_cache_for_file

file テーブル関数の使用時に、スキーマ推論で cache を使用します

​

schema_inference_use_cache_for_hdfs

hdfs table functio の使用時に、スキーマ推論で cache を使用します。

​

schema_inference_use_cache_for_s3

S3 table functio の使用時に、スキーマ推論で cache を使用します

​

schema_inference_use_cache_for_url

url table functio の使用時に、スキーマ推論で cache を使用します

​

secondary_indices_enable_bulk_filtering

インデックスの一括フィルタリングアルゴリズムを有効にします。通常はこちらのほうが常に優れている想定ですが、互換性の確保と動作制御のためにこの設定を用意しています。

​

select_sequential_consistency

この設定は SharedMergeTree と ReplicatedMergeTree で動作が異なります。SharedMergeTree における select_sequential_consistency の動作の詳細については、SharedMergeTree consistency を参照してください。

SELECT クエリに対する逐次整合性を有効または無効にします。使用するには、insert_quorum_parallel を無効にする必要があります (デフォルトでは有効です) 。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

使用方法

逐次整合性が有効な場合、ClickHouse は、insert_quorum を使用して以前に実行されたすべての INSERT クエリのデータを含むレプリカに対してのみ、クライアントによる SELECT クエリの実行を許可します。クライアントが不完全なレプリカを参照すると、ClickHouse は例外を生成します。SELECT クエリには、まだレプリカのクォーラムに書き込まれていないデータは含まれません。

insert_quorum_parallel が有効な場合 (デフォルト) 、select_sequential_consistency は機能しません。これは、並列の INSERT クエリが異なるクォーラムレプリカの集合に書き込まれる可能性があるため、1 つのレプリカがすべての書き込みを受け取っている保証がないからです。

関連項目:

• insert_quorum
• insert_quorum_timeout
• insert_quorum_parallel

​

send_logs_level

指定した最小レベル以上のサーバーのテキストログをクライアントに送信します。有効な値: ‘trace’, ‘debug’, ‘information’, ‘warning’, ‘error’, ‘fatal’, ‘none’

​

send_logs_source_regexp

指定した正規表現に一致するログソース名を持つserverのテキストログを送信します。空の場合は、すべてのソースが対象です。

​

send_profile_events

クライアントへの ProfileEvents パケットの送信を有効または無効にします。

profile events を必要としないクライアントのネットワークトラフィックを削減するため、この設定は無効にできます。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

send_progress_in_http_headers

clickhouse-server のレスポンスで、X-ClickHouse-Progress HTTP レスポンスヘッダーの有効/無効を切り替えます。

詳細については、HTTP インターフェイスの説明を参照してください。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

send_table_structure_on_insert_with_inline_data

無効になっていて、かつ INSERT クエリにインラインデータが含まれている場合、サーバーはネイティブプロトコル経由でテーブル構造とカラムのデフォルト値をクライアントに返しません。代わりに、サーバー自身がインラインデータを解析します。これにより、ネイティブプロトコル経由で小規模な INSERT を多数実行する際のパフォーマンスが向上することがあります。

​

send_timeout

ネットワークにデータを送信する際のタイムアウトです。単位は秒です。クライアントがデータを送信する必要があるにもかかわらず、この間隔内に1バイトも送信できない場合は、例外が発生します。クライアント側でこの設定を行うと、ソケットの receive_timeout もサーバー側の対応する接続先に設定されます。

​

serialize_query_plan

分散処理用にクエリプランをシリアル化します

​

serialize_string_in_memory_with_zero_byte

集約中に、String 型の値を末尾にゼロバイトを付けてシリアライズします。互換性のないバージョンが混在するクラスターにクエリする際の互換性を維持するには、有効にしてください。

​

session_timezone

現在の session またはクエリの暗黙のタイムゾーンを設定します。 暗黙のタイムゾーンとは、明示的にタイムゾーンが指定されていない DateTime/DateTime64 型の値に適用されるタイムゾーンです。 この設定は、グローバルに設定された (server レベルの) 暗黙のタイムゾーンよりも優先されます。 値 '' (空文字列) は、現在の session またはクエリの暗黙のタイムゾーンが server time zone と同じであることを意味します。

関数 timeZone() と serverTimeZone() を使用すると、session のタイムゾーンと server のタイムゾーンを取得できます。

設定可能な値:

• system.time_zones に含まれる任意のタイムゾーン名 (例: Europe/Berlin、UTC、Zulu)

例:

SELECT timeZone(), serverTimeZone() FORMAT CSV

"Europe/Berlin","Europe/Berlin"

SELECT timeZone(), serverTimeZone() SETTINGS session_timezone = 'Asia/Novosibirsk' FORMAT CSV

"Asia/Novosibirsk","Europe/Berlin"

タイムゾーンが明示的に指定されていない内側の DateTime に、セッションのタイムゾーン ‘America/Denver’ を割り当てます。

SELECT toDateTime64(toDateTime64('1999-12-12 23:23:23.123', 3), 3, 'Europe/Zurich') SETTINGS session_timezone = 'America/Denver' FORMAT TSV

1999-12-13 07:23:23.123

DateTime/DateTime64 を parse するすべての関数が session_timezone に従うわけではありません。そのため、気付きにくい error につながることがあります。 以下の例と説明を参照してください。

CREATE TABLE test_tz (`d` DateTime('UTC')) ENGINE = Memory AS SELECT toDateTime('2000-01-01 00:00:00', 'UTC');

SELECT *, timeZone() FROM test_tz WHERE d = toDateTime('2000-01-01 00:00:00') SETTINGS session_timezone = 'Asia/Novosibirsk'
0 rows in set.

SELECT *, timeZone() FROM test_tz WHERE d = '2000-01-01 00:00:00' SETTINGS session_timezone = 'Asia/Novosibirsk'
┌───────────────────d─┬─timeZone()───────┐
│ 2000-01-01 00:00:00 │ Asia/Novosibirsk │
└─────────────────────┴──────────────────┘

これは、パース処理のパイプラインが異なるために発生します。

• 最初の SELECT クエリで、タイムゾーンを明示的に指定せずに使用した toDateTime() は、設定 session_timezone とグローバルタイムゾーンに従います。
• 2 つ目のクエリでは、DateTime は String からパースされ、既存のカラム d の型とタイムゾーンを引き継ぎます。そのため、設定 session_timezone とグローバルタイムゾーンは反映されません。

関連項目

• timezone

​

set_overflow_mode

データ量がいずれかの上限を超えた場合の動作を設定します。

設定可能な値:

• throw: 例外をスローします (デフォルト) 。
• break: クエリの実行を停止し、ソースデータが尽きた場合と同様に、 部分的な結果を返します。

​

shared_merge_tree_sequential_consistency_initial_parts_update_backoff_ms

SharedMergeTree で select_sequential_consistency を使用する場合の、パーツ更新時の初期バックオフ (ミリ秒) 。ClickHouse Cloud でのみ利用できます。

​

shared_merge_tree_sequential_consistency_max_parts_update_backoff_ms

SharedMergeTree で select_sequential_consistency を使用する場合の、パーツ更新における最大バックオフ時間 (ミリ秒) 。ClickHouse Cloud でのみ利用できます。

​

shared_merge_tree_sequential_consistency_parts_update_max_retries

SharedMergeTree で select_sequential_consistency を使用する際のパーツ更新の最大再試行回数。ClickHouse Cloud でのみ利用できます。

​

shared_merge_tree_sync_parts_on_partition_operations

SMT テーブルで MOVE|REPLACE|ATTACH パーティション操作を行った後、データパーツ群を自動的に同期します。Cloud のみ

​

short_circuit_function_evaluation

if、multiIf、and、および or 関数を、短絡評価 に従って評価できるようにします。これにより、これらの関数内の複雑な式の実行を最適化し、起こり得る例外 (想定されない場合のゼロ除算など) を防ぐのに役立ちます。

設定可能な値:

• enable — 短絡関数評価に適した関数 (例外をスローする可能性がある、または計算負荷が高い関数) で有効にします。
• force_enable — すべての関数で短絡関数評価を有効にします。
• disable — 短絡関数評価を無効にします。

​

short_circuit_function_evaluation_for_nulls

いずれかの引数がNULLの場合にNULLを返す関数の評価を最適化します。関数の引数に含まれるNULL値の割合がshort_circuit_function_evaluation_for_nulls_thresholdを超えると、システムは関数を行単位で評価する処理をスキップします。代わりに、すべての行に対して即座にNULLを返すことで、不要な計算を回避します。

​

short_circuit_function_evaluation_for_nulls_threshold

すべての引数が非 NULL 値である行に対してのみ Nullable 引数を持つ関数を実行するための、NULL 値の比率のしきい値です。設定 short_circuit_function_evaluation_for_nulls が有効な場合に適用されます。 NULL 値を含む行の比率が全行数に対してこのしきい値を超えると、それらの NULL 値を含む行は評価されません。

​

show_processlist_include_internal

SHOW PROCESSLIST クエリの出力に内部の補助プロセスを表示します。

内部プロセスには、Dictionary の再読み込み、リフレッシャブルmaterialized view の再読み込み、SHOW ... クエリで実行される補助的な SELECT、破損したテーブルに対処するために内部で実行される補助的な CREATE DATABASE ... クエリなどが含まれます。

​

show_remote_databases_in_system_tables

別名: show_data_lake_catalogs_in_system_tables

システムテーブルにリモートデータベース (データレイクカタログ、MySQL、PostgreSQL) を表示するかどうかを制御します。

​

show_table_uuid_in_table_create_query_if_not_nil

SHOW TABLE クエリの表示方法を設定します。

設定可能な値:

• 0 — クエリはテーブル UUID なしで表示されます。
• 1 — クエリはテーブル UUID 付きで表示されます。

​

single_join_prefer_left_table

単一の JOIN で識別子が曖昧な場合は、左側のテーブルを優先します

​

skip_redundant_aliases_in_udf

ユーザー定義関数では、使いやすくするために冗長な別名は使用されず (置換されず) 、

設定可能な値:

• 1 — UDF では別名がスキップされます (置換されます) 。
• 0 — UDF では別名はスキップされません (置換されません) 。

例

有効時と無効時の違い:

クエリ:

SET skip_redundant_aliases_in_udf = 0;
CREATE FUNCTION IF NOT EXISTS test_03274 AS ( x ) -> ((x + 1 as y, y + 2));

EXPLAIN SYNTAX SELECT test_03274(4 + 2);

結果:

SELECT ((4 + 2) + 1 AS y, y + 2)

クエリ:

SET skip_redundant_aliases_in_udf = 1;
CREATE FUNCTION IF NOT EXISTS test_03274 AS ( x ) -> ((x + 1 as y, y + 2));

EXPLAIN SYNTAX SELECT test_03274(4 + 2);

結果:

SELECT ((4 + 2) + 1, ((4 + 2) + 1) + 2)

​

skip_unavailable_shards

利用できない分片を通知せずにスキップするかどうかを切り替えます。

分片は、そのすべてのレプリカが利用できない場合に利用不可と見なされます。レプリカが利用できないのは、次の場合です。

• ClickHouse が何らかの理由でレプリカに接続できない場合。

  ClickHouse はレプリカへの接続時に複数回試行します。これらの試行がすべて失敗すると、そのレプリカは利用不可と見なされます。

• レプリカの名前を DNS で解決できない場合。

  レプリカのホスト名を DNS で解決できない場合は、次のような状況が考えられます。

  • レプリカのホストに DNS レコードがありません。これは、たとえば Kubernetes のような動的 DNS を使用するシステムで発生することがあり、ダウンタイム中はノードの名前解決ができなくても、エラーではありません。

  • 設定エラー。ClickHouse の設定ファイルに誤ったホスト名が含まれています。

設定可能な値:

• 1 — スキップが有効です。

  分片が利用できない場合、ClickHouse は一部のデータに基づく結果を返し、ノードの可用性の問題は報告しません。

• 0 — スキップが無効です。

  分片が利用できない場合、ClickHouse は例外をスローします。

​

sleep_after_receiving_query_ms

TCPHandler がクエリを受信した後にスリープする時間

​

sleep_in_send_data_ms

TCPHandler でデータ送信時に待機する時間

​

sleep_in_send_tables_status_ms

TCPHandler でテーブルのステータス応答を送信する際の待機時間

​

sort_overflow_mode

ソート前に受信した行数がいずれかの制限を超えた場合の動作を設定します。

設定可能な値:

• throw: 例外を発生させます。
• break: クエリの実行を停止し、部分的な結果を返します。

​

split_intersecting_parts_ranges_into_layers_final

FINAL 最適化時に、交差するパーツの範囲をレイヤーに分割します

​

split_parts_ranges_into_intersecting_and_non_intersecting_final

FINAL 最適化時に、パーツの範囲を交差するものと交差しないものに分割します

​

splitby_max_substrings_includes_remaining_string

引数 max_substrings > 0 を指定した splitBy*() 関数が、結果配列の最後の要素に残りの文字列を含めるかどうかを制御します。

設定可能な値:

• 0 - 残りの文字列は結果配列の最後の要素に含まれません。
• 1 - 残りの文字列は結果配列の最後の要素に含まれます。これは Spark の split() 関数および Python の ‘string.split()’ メソッドと同じ動作です。

​

stop_refreshable_materialized_views_on_startup

サーバーの起動時に、SYSTEM STOP VIEWS を使用した場合と同様に、リフレッシュ可能なマテリアライズドビューがスケジュールされないようにします。これらはその後、SYSTEM START VIEWS または SYSTEM START VIEW <name> で手動で開始できます。新しく作成されたビューにも適用されます。リフレッシュ可能でない materialized view には影響しません。

​

storage_file_read_method

ストレージファイルからデータを読み取る方法です。指定できる値は read、pread、mmap のいずれかです。mmap メソッドは clickhouse-server には適用されません (clickhouse-local 向けです) 。

​

storage_system_stack_trace_pipe_read_timeout_ms

system.stack_trace テーブルをクエリする際に、スレッドから情報を受け取るためにパイプから読み取る最大時間です。この設定はテスト目的で使用されるもので、ユーザーが変更することは想定されていません。

​

stream_flush_interval_ms

ストリーミングを行うテーブルで、タイムアウトが発生した場合、またはスレッドが max_insert_block_size 行を生成した場合に機能します。

デフォルト値は 7500 です。

値が小さいほど、データはより頻繁にテーブルへフラッシュされます。値を小さくしすぎると、パフォーマンスが低下します。

​

stream_like_engine_allow_direct_select

Kafka、RabbitMQ、FileLog、Redis Streams、S3Queue、AzureQueue、NATS エンジンに対する直接 SELECT クエリを許可します。アタッチされた materialized view がある場合は、この設定を有効にしていても SELECT クエリは許可されません。 アタッチされた materialized view がない場合、この設定を有効にするとデータを読み取れるようになります。通常、読み取ったデータはキューから削除されるため、注意してください。読み取ったデータが削除されないようにするには、関連するエンジン設定を適切に構成する必要があります。

​

stream_like_engine_insert_queue

stream 系の engine が複数の queue から読み取る場合、書き込み時には insert 先の queue を 1 つ選択する必要があります。Redis Streams と NATS で使用されます。

​

stream_poll_timeout_ms

ストリーミングストレージから/へのデータのポーリング時のタイムアウト。

​

system_events_show_zero_values

system.events から、値が 0 のイベントも選択できるようにします。

一部の監視システムでは、メトリクスの値が 0 の場合でも、各チェックポイントでそれらにすべてのメトリクス値を渡す必要があります。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

例

クエリ

SELECT * FROM system.events WHERE event='QueryMemoryLimitExceeded';

結果

Ok.

クエリ

SET system_events_show_zero_values = 1;
SELECT * FROM system.events WHERE event='QueryMemoryLimitExceeded';

結果

┌─event────────────────────┬─value─┬─description───────────────────────────────────────────┐
│ QueryMemoryLimitExceeded │     0 │ クエリのメモリ制限を超えた回数。 │
└──────────────────────────┴───────┴───────────────────────────────────────────────────────┘

​

system_metric_log_show_zero_values_in_histograms

値がゼロのヒストグラムデータを system.metric_log のネストされた histograms カラムに書き込むかどうかを制御します。

デフォルトでは、観測の合計 count がゼロのヒストグラムはスキップされ、出力される各ヒストグラム内でも、観測のない bucket エントリは histogram map から省略されます。これを有効にすると、count に関係なくすべてのヒストグラムとすべての bucket が書き込まれます。これは、各チェックポイントですべての Metric が必ず現れる必要がある監視システムで役立ちます。

設定可能な値:

• 0 — 無効。count = 0 のヒストグラムは出力されません。出力されるヒストグラムには、少なくとも 1 回観測された bucket のみが含まれます。
• 1 — 有効。すべてのヒストグラムが書き込まれ、すべての bucket 境界が histogram に現れます。

​

table_engine_read_through_distributed_cache

ClickHouse Cloud でのみ有効です。テーブルエンジン / テーブル関数 (s3、azure など) 経由で、分散キャッシュからの読み取りを許可します

​

table_function_remote_max_addresses

remote 関数で、パターンから生成されるアドレスの最大数を設定します。

設定可能な値:

• 正の整数。

​

tcp_keep_alive_timeout

TCP が keepalive プローブの送信を開始するまでに、接続がアイドル状態のままでいる時間 (秒)

​

temporary_data_in_cache_reserve_space_wait_lock_timeout_milliseconds

ファイルシステムキャッシュ内の一時データの領域予約時にキャッシュをロックするまでの待機時間

​

temporary_files_buffer_size

一時ファイルの書き込み用バッファのサイズです。バッファサイズが大きいほどシステムコールは少なくなりますが、メモリ消費量は増えます。

​

temporary_files_codec

ディスク上でのソートおよび結合処理で使用される一時ファイルの圧縮コーデックを設定します。

設定可能な値:

• LZ4 — LZ4 圧縮が適用されます。
• NONE — 圧縮は適用されません。

​

text_index_density_threshold

lazy posting list モードでアルゴリズムを選択するための密度しきい値です。 しきい値未満: leapfrog 方式の積集合。しきい値以上: brute-force bitmap。

​

text_index_hint_max_selectivity

転置テキスト索引から構築されたヒントを使用するための、フィルターの最大選択率。

​

text_index_like_max_postings_to_read

辞書スキャンによるテキスト索引の LIKE 評価が有効な場合に読み取る、大きな posting の最大数です。

use_text_index_like_evaluation_by_dictionary_scan を有効にする必要があります。

​

text_index_like_min_pattern_length

辞書スキャンによるテキスト索引の LIKE 評価を使用するために必要な、LIKE/ILIKE パターン内の英数字検索語の最小長。 このしきい値より短いパターンは、一致する辞書トークンが多くなりすぎるため、コストの高いスキャンを避ける目的でスキップされます。

use_text_index_like_evaluation_by_dictionary_scan を有効にする必要があります。

​

text_index_posting_list_apply_mode

テキスト索引クエリ時にポスティングリストをどのように適用するかを制御します。 ‘materialize’ (デフォルト) は、ポスティングリストを Roaring Bitmap に即座にデコードします。 ‘lazy’ は、カーソルベースのオンデマンドデコードを使用します (V2 索引フォーマットおよび allow_experimental_text_index_lazy_apply が必要です) 。

​

throw_if_no_data_to_insert

空の INSERT を許可または禁止します。デフォルトで有効になっており、空の INSERT ではエラーになります。clickhouse-client を使用する INSERT、または gRPC インターフェイス を使用する INSERT にのみ適用されます。

​

throw_on_error_from_cache_on_write_operations

書き込み操作 (INSERT、merges) のキャッシュ時に、cache で発生したエラーを無視します

​

throw_on_max_partitions_per_insert_block

max_partitions_per_insert_block に達したときの動作を制御します。

設定可能な値:

• true - 挿入ブロックが max_partitions_per_insert_block に達すると、例外をスローします。
• false - max_partitions_per_insert_block に達すると、警告をログに記録します。

max_partitions_per_insert_block を変更する際に、ユーザーへの影響を把握するのに役立ちます。

​

throw_on_unsupported_query_inside_transaction

トランザクション内で未対応のクエリが使用された場合に例外をスローします

​

timeout_before_checking_execution_speed

指定した秒数が経過した後、実行速度が遅すぎないこと (min_execution_speedを下回らないこと) を確認します。

​

timeout_overflow_mode

クエリの実行時間が max_execution_time を超えた場合、または 推定実行時間が max_estimated_execution_time を超えた場合の動作を設定します。

設定可能な値:

• throw: 例外を発生させます (デフォルト) 。
• break: クエリの実行を停止し、データが尽きたかのように 部分的な結果を返します。

​

timeout_overflow_mode_leaf

リーフノードで実行されるクエリの実行時間が max_execution_time_leaf を超えた場合の動作を設定します。

設定可能な値:

• throw: 例外をスローします (デフォルト) 。
• break: クエリの実行を停止し、ソースデータが尽きた場合と同様に、部分的な結果を返します。

​

totals_auto_threshold

totals_mode = 'auto' で使用する閾値です。 「WITH TOTALS 修飾子」のセクションを参照してください。

​

totals_mode

HAVING が指定されている場合、および max_rows_to_group_by と group_by_overflow_mode = ‘any’ が設定されている場合に、TOTALS をどのように計算するかを指定します。 「WITH TOTALS 修飾子」セクションを参照してください。

​

trace_profile_events

profile events が更新されるたびに、profile event の名前と増分の値に加えて stacktraces を収集し、trace_log に送信するかどうかを設定します。

設定可能な値:

• 1 — profile events のトレーシングを有効にします。
• 0 — profile events のトレーシングを無効にします。

​

trace_profile_events_list

設定 trace_profile_events が有効な場合、トレースするイベントを、カンマ区切りで指定した名前のリストに限定します。 trace_profile_events_list が空文字列 (デフォルト) の場合は、すべての profile events をトレースします。

例の値: ‘DiskS3ReadMicroseconds,DiskS3ReadRequestsCount,SelectQueryTimeMicroseconds,ReadBufferFromS3Bytes’

この設定を使用すると、多数のクエリに対するデータをより正確に収集できます。これを使用しないと、大量のイベントによって内部システムログキューがオーバーフローし、一部のイベントが破棄される可能性があるためです。

​

transfer_overflow_mode

データ量がいずれかの制限を超えた場合の動作を設定します。

設定可能な値:

• throw: 例外をスローします (既定値) 。
• break: クエリの実行を停止し、ソースデータが尽きた場合と同じように、 部分的な結果を返します。

​

transform_null_in

IN 演算子において、NULL 値同士の等価性を有効にします。

デフォルトでは、NULL は未定義の値を意味するため、NULL 値は比較できません。したがって、expr = NULL という比較は常に false を返す必要があります。この設定を有効にすると、IN 演算子では NULL = NULL が true を返します。

設定可能な値:

• 0 — IN 演算子における NULL 値の比較は false を返します。
• 1 — IN 演算子における NULL 値の比較は true を返します。

例

null_in テーブルについて考えます:

┌──idx─┬─────i─┐
│    1 │     1 │
│    2 │  NULL │
│    3 │     3 │
└──────┴───────┘

クエリ:

SELECT idx, i FROM null_in WHERE i IN (1, NULL) SETTINGS transform_null_in = 0;

結果:

┌──idx─┬────i─┐
│    1 │    1 │
└──────┴──────┘

クエリ:

SELECT idx, i FROM null_in WHERE i IN (1, NULL) SETTINGS transform_null_in = 1;

結果:

┌──idx─┬─────i─┐
│    1 │     1 │
│    2 │  NULL │
└──────┴───────┘

関連項目

• IN演算子におけるNULLの処理

​

traverse_shadow_remote_data_paths

system.remote_data_paths のクエリ時に、実際のテーブルデータに加えて凍結データ (shadow ディレクトリ) も走査します

​

union_default_mode

SELECT クエリの結果を結合するモードを設定します。この設定は、UNION ALL または UNION DISTINCT を明示的に指定せずに UNION を使用した場合にのみ適用されます。

設定可能な値:

• 'DISTINCT' — ClickHouse は、重複する行を削除してクエリを結合した結果を出力します。
• 'ALL' — ClickHouse は、重複する行を含む、クエリ結合結果のすべての行を出力します。
• '' — UNION とともに使用すると、ClickHouse は例外を生成します。

例については UNION を参照してください。

​

unique_key_max_encoded_size

単一の UNIQUE KEY 行の順序保持バイナリエンコーディングの最大サイズ (バイト単位) 。

​

unknown_packet_in_send_data

N 番目のデータパケットで、データの代わりに不明なパケットを送信します

​

update_parallel_mode

同時実行される更新クエリの動作を決定します。

設定可能な値:

• sync - すべての UPDATE クエリを順番に実行します。
• auto - あるクエリで更新されるカラムと別のクエリの式で使用されるカラムの間に依存関係がある UPDATE クエリのみを、順番に実行します。
• async - UPDATE クエリを同期しません。

​

update_sequential_consistency

true の場合、update の実行前にパーツセットが最新バージョンに更新されます。

​

url_base

url table function および URL table engine で、相対 URL の解決に使用される base URL です。

設定すると、相対 URL は次のように解決されます。

• パス相対 URL (例: data.csv) : RFC 3986 に従って base URL の path と結合されます。base path 内の最後の / より後ろはすべて相対 URL で置き換えられるため、末尾のスラッシュの有無が重要です。つまり、https://example.com/dir/ + data.csv = https://example.com/dir/data.csv ですが、https://example.com/dir + data.csv = https://example.com/data.csv になります。base に path がない場合 (例: https://example.com) は、/ が挿入されて https://example.com/data.csv になります。相対 URL 内のドットセグメント (./ および ../) は正規化されます: https://example.com/dir/ + ../a.csv = https://example.com/a.csv。
• ホスト相対 URL (例: /test/data.csv) : base URL の scheme と host を基準に解決されます。
• scheme 相対 URL (例: //other.com/test/data.csv) : base URL の scheme を使って解決されます。
• クエリのみの参照 (例: ?x=1) : base URL の path に追加されます (既存の query/fragment は置き換えられます) 。
• フラグメントのみの参照 (例: #frag) : 既存の query string は保持したまま base URL に追加されます (既存の fragment は置き換えられます) 。
• 空の参照: fragment を除いた base URL を返します。

たとえば、url_base が https://example.com/def/ の場合:

• data.csv は https://example.com/def/data.csv に解決されます
• /test/data.csv は https://example.com/test/data.csv に解決されます
• //other.com/test/data.csv は https://other.com/test/data.csv に解決されます

​

use_async_executor_for_materialized_views

materialized view のクエリ実行に非同期方式を使用し、必要に応じてマルチスレッドでも実行します。これにより、INSERT 中のビュー処理を高速化できる可能性がありますが、その分メモリ消費量も増えます。

​

use_cache_for_count_from_files

テーブル関数 file/s3/url/hdfs/azureBlobStorage で、ファイルから count を行う際の行数のキャッシュを有効にします。

デフォルトで有効です。

​

use_client_time_zone

サーバーのタイムゾーンではなく、DateTime文字列の値の解釈にクライアントのタイムゾーンを使用します。

​

use_compact_format_in_distributed_parts_names

Distributed エンジンのテーブルへのバックグラウンド (distributed_foreground_insert) INSERT で、ブロックの保存に compact フォーマットを使用します。

設定可能な値:

• 0 — user[:password]@host:port#default_database のディレクトリフォーマットを使用します。
• 1 — [shard{shard_index}[_replica{replica_index}]] のディレクトリフォーマットを使用します。

• use_compact_format_in_distributed_parts_names=0 の場合、クラスター定義の変更はバックグラウンド INSERT に適用されません。
• use_compact_format_in_distributed_parts_names=1 の場合、クラスター定義内のノードの順序を変更すると shard_index/replica_index も変わるため、注意してください。

​

use_concurrency_control

サーバーの同時実行制御 (グローバルなサーバー設定 concurrent_threads_soft_limit_num および concurrent_threads_soft_limit_ratio_to_cores を参照) に従います。無効にすると、サーバーが過負荷の状態でも、より多くのスレッドを使用できるようになります (通常の用途では推奨されず、主にテストで必要です) 。

Cloud でのデフォルト値: 0.

​

use_hash_table_stats_for_join_reordering

join の並べ替え時に、収集したハッシュテーブル統計をカーディナリティ推定に使用できるようにします

​

use_hedged_requests

リモートクエリに対するヘッジドリクエストのロジックを有効にします。これにより、1 つのクエリに対して異なるレプリカへの複数の接続を確立できます。 既存のレプリカへの接続が hedged_connection_timeout 以内に確立されなかった場合、 または receive_data_timeout 以内にデータを受信できなかった場合は、新しい接続が有効になります。クエリは、空でない Progress パケット (allow_changing_replica_until_first_data_packet の場合は Data パケット) を最初に送信した接続を使用し、 それ以外の接続はキャンセルされます。max_parallel_replicas > 1 のクエリもサポートされます。

デフォルトで有効です。

Cloud でのデフォルト値: 0。

​

use_hive_partitioning

有効にすると、ClickHouse はファイル系のテーブルエンジン File/S3/URL/HDFS/AzureBlobStorage のパス (/name=value/) 内にある Hive スタイルのパーティション化を検出し、クエリでパーティションカラムを仮想カラムとして使用できるようにします。これらの仮想カラムの名前はパーティション化されたパス内の名前と同じですが、先頭に _ が付きます。

​

use_iceberg_metadata_files_cache

有効にすると、Iceberg テーブル関数および Iceberg ストレージで Iceberg メタデータファイルのキャッシュを利用できます。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

use_iceberg_partition_pruning

Icebergテーブルに対してIcebergのパーティションプルーニングを使用します

​

use_index_for_in_with_subqueries

IN 演算子の右辺にサブクエリまたはテーブル式がある場合、索引の使用を試みます。

​

use_index_for_in_with_subqueries_max_values

フィルタリングでテーブルの索引を使用する場合の、IN 演算子の右辺にある Set の最大サイズです。大規模なクエリで追加のデータ構造を準備することによる性能低下やメモリ使用量の増加を防ぐことができます。0 は制限なしを意味します。

​

use_join_disjunctions_push_down

JOIN 条件の OR で結合された部分を、対応する入力側にプッシュダウン (「部分的なプッシュダウン」) するかどうかを有効にします。 これにより、ストレージエンジンがより早い段階でフィルタリングできるようになり、読み込むデータ量を減らせる可能性があります。 この最適化は元の意味を変えず、各最上位の OR 分岐が対象側に対して少なくとも 1 つの決定論的な 条件式を持つ場合にのみ適用されます。

​

use_legacy_to_time

有効にすると、従来の toTime 関数を使用できます。この関数は、時刻を保持したまま、日時を特定の固定日付に変換します。 無効な場合は、新しい toTime 関数が使用され、さまざまな型のデータを Time 型に変換します。 従来の古い関数は、toTimeWithFixedDate として常に利用できます。

​

use_lightweight_primary_key_index_analysis

長い主キーを持つ MergeTree テーブルの主キー索引解析を最適化します。

有効にすると、索引解析の実行時間は主キーの長さではなく、主にクエリのフィルタ条件の複雑さ (実際に使用されるキーカラム) に依存します。そのため、数個のカラムだけをフィルタするクエリでは、ソートキーを拡張しても索引解析に対する追加のオーバーヘッドはごくわずかです。

設定可能な値:

• 0 — 無効。索引解析ではすべての主キーカラムが処理されます。
• 1 — 有効。

​

use_page_cache_for_disks_without_file_cache

ファイルシステムキャッシュが有効でないリモートディスクでは、ユーザー空間のページキャッシュを使用します。

​

use_page_cache_for_local_disks

ローカルディスクから読み取る際に、ユーザー空間ページキャッシュを使用します。テスト用途の設定であり、実際の運用でパフォーマンスが向上する可能性は低いです。local_filesystem_read_method = 'pread' または 'read' が必要です。OS page cache は無効になりません。これを無効にするには min_bytes_to_use_direct_io を使用できます。影響するのは通常のテーブルのみで、file() テーブル関数や File() テーブルエンジンには影響しません。

​

use_page_cache_for_object_storage

オブジェクトストレージのテーブル関数 (s3、azure、hdfs) およびテーブルエンジン (S3、Azure、HDFS) から読み込む際に、ユーザー空間ページキャッシュを使用します。

​

use_page_cache_with_distributed_cache

分散キャッシュを使用する場合は、ユーザー空間ページキャッシュを使用します。

​

use_paimon_partition_pruning

Paimon table function で Paimon のパーティションプルーニングを使用します

​

use_parquet_metadata_cache

有効にすると、Parquet フォーマットでメタデータキャッシュを利用できます。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

use_partition_pruning

別名: use_partition_key

MergeTree テーブルのクエリ実行時に、パーティションキーを使用して不要なパーティションを除外します。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_primary_key

MergeTree テーブルで、クエリ実行時のグラニュールのプルーニングに主キーを使用します。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_query_cache

有効にすると、SELECT クエリで query cache を利用できます。パラメーター enable_reads_from_query_cache および enable_writes_to_query_cache によって、cache の使用方法をより細かく制御できます。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

use_query_condition_cache

クエリ条件キャッシュを有効にします。この cache は、WHERE 句の条件を満たさないデータパーツ内のグラニュールの範囲を保存し、 後続のクエリでこの情報を一時的な索引として再利用します。

設定可能な値:

• 0 - 無効
• 1 - 有効

​

use_reader_executor

実験的機能です。従来の幾重にも重なった読み取りバッファではなく、新しいパイプライン ReaderExecutor を通して読み取りを行います。ReaderExecutor がまだサポートしていない構成では、従来のパスにフォールバックします。

​

use_roaring_bitmap_iceberg_positional_deletes

Iceberg の positional delete に roaring bitmap を使用します。

​

use_skip_indexes

クエリの実行時にデータスキッピングインデックスを使用します。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_skip_indexes_for_disjunctions

スキップ索引を使用して、AND と OR が混在する WHERE フィルターを評価します。例: WHERE A = 5 AND (B = 5 OR C = 5)。 無効にした場合でも、WHERE 条件の評価には引き続きスキップ索引が使用されますが、条件には AND で結合された句しか含められません。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_skip_indexes_for_top_k

TopK フィルタリングでデータスキッピングインデックスを使用するかどうかを有効にします。

有効にすると、ORDER BY <column> LIMIT n クエリのカラムに minmax スキップ索引が存在する場合、オプティマイザは minmax 索引を使用して、最終結果に関係のないグラニュールをスキップしようとします。これにより、クエリのレイテンシを低減できます。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_skip_indexes_if_final

FINAL 修飾子を指定したクエリの実行時に、スキップ索引を使用するかどうかを制御します。

スキップ索引によって最新データを含む行 (granules) が除外される可能性があり、その結果、FINAL 修飾子を指定したクエリで不正確な結果が返されることがあります。この設定を有効にすると、FINAL 修飾子を使用している場合でもスキップ索引が適用され、パフォーマンスが向上する可能性がありますが、その一方で直近の更新を見落とすおそれがあります。この設定は、use_skip_indexes_if_final_exact_mode 設定と合わせて有効にする必要があります (デフォルトでは有効です) 。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_skip_indexes_if_final_exact_mode

FINAL 修飾子付きでクエリを実行するときに、正しい結果を返せるよう、スキップ索引が返したグラニュールを新しいパーツ内で展開するかどうかを制御します。

スキップ索引を使用すると、最新データを含む行 (グラニュール) が除外され、結果が不正確になる可能性があります。この設定を有効にすると、スキップ索引が返した範囲と重なる新しいパーツをスキャンすることで、正しい結果を返せるようになります。アプリケーションで、スキップ索引の参照に基づく近似結果でも問題ない場合にのみ、この設定を無効にしてください。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_skip_indexes_on_data_read

データ読み取り時にデータスキッピングインデックスを使用するかどうかを制御します。

有効にすると、スキップ索引はクエリ実行の開始前に事前解析されるのではなく、各データグラニュールの読み取り時に動的に評価されます。これにより、クエリ開始時のレイテンシを低減できます。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_statistics

/// ‘use_primary_key’ および ‘use_skip_indexes’ との整合性のため、‘allow_statistics_optimize’ よりこちらが推奨されます 統計を使用してクエリを最適化できるようにします

​

use_statistics_cache

クエリで statistics cache を使用すると、各パーツの統計情報を読み込むオーバーヘッドを回避できます

​

use_statistics_for_part_pruning

クエリ実行時に、統計を使用してパーツを絞り込みます。

有効にすると、SELECT クエリでの剪枝ではカラム STATISTICS (例: MinMax statistics) を使用し、データを読み取る前に一致するデータを含まないパーツを除外します。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_strict_insert_block_limits

有効にすると、最小および最大の挿入ブロックサイズ制限の両方が厳密に適用されます。

ブロックは、次の場合に出力されます。

• 最小しきい値 (AND) : min_insert_block_size_rows と min_insert_block_size_bytes の両方に達した場合。
• 最大しきい値 (OR) : max_insert_block_size_rows または max_insert_block_size_bytes のいずれかに達した場合。

無効な場合、ブロックは次の場合に出力されます。

• 最小しきい値 (OR) : min_insert_block_size_rows または min_insert_block_size_bytes のいずれかに達した場合。

注: max の設定が min の設定より小さい場合は、max の制限が優先されるため、最小しきい値に達する前にブロックが出力されます。

注: この設定は非同期 INSERT では自動的に無効になります。これは、非同期 INSERT ではエントリごとの重複排除トークンが付与され、厳密な制限を適用するために必要なブロックの分割と両立しないためです。

デフォルトでは無効です。

​

use_structure_from_insertion_table_in_table_functions

データからのスキーマ推論ではなく、挿入先テーブルの構造を使用します。設定可能な値: 0 - 無効、1 - 有効、2 - 自動

​

use_text_index_header_cache

デシリアライズされたテキスト索引ヘッダーのcacheを使用するかどうかを指定します。 テキスト索引ヘッダーキャッシュを使用すると、多数のテキスト索引クエリを処理する際のレイテンシを大幅に低減し、スループットを向上させることができます。

​

use_text_index_like_evaluation_by_dictionary_scan

転置テキスト索引のDictionaryをスキャンして、LIKE/ILIKEクエリの評価を有効にします。

​

use_text_index_postings_cache

デシリアライズ済みのテキスト索引 posting list の cache を使用するかどうか。 テキスト索引 posting list の cache を使用すると、多数のテキスト索引クエリを実行する際のレイテンシを大幅に低減し、スループットを向上させることができます。

​

use_text_index_tokens_cache

デシリアライズされたテキスト索引トークン情報のキャッシュを使用するかどうか。 テキスト索引トークンキャッシュを使用すると、大量のテキスト索引クエリを処理する際のレイテンシを大幅に低減し、スループットを向上させることができます。

​

use_top_k_dynamic_filtering

ORDER BY <column> LIMIT n クエリの実行時に、動的フィルタリング最適化を有効にします。

有効にすると、クエリ実行エンジンは、結果セットの最終的な top N 行に含まれないグラニュールや行をスキップしようとします。この最適化は動的な性質を持つため、レイテンシの改善度はデータ分布や、クエリ内の他の述語条件の有無に依存します。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_top_k_dynamic_filtering_for_variable_length_types

ソートカラムが可変長のデータ型 (例: String、Array、Map、可変長要素を含む Tuple) である場合に、use_top_k_dynamic_filtering を適用できるようにします。

このような型では、動的フィルターによる行ごとのしきい値比較のコストが、カラムの辞書順最小値が支配的で (たとえば空文字列が大半を占める場合) 、スキップできるグラニュールが少ないときには、得られる削減効果を上回ることがあります。この場合、動的フィルターはクエリのレイテンシを改善するどころか、かえって悪化させます。

この設定が 0 の場合、動的フィルタリングは、値がメモリ上で固定の最大サイズを持つカラム (数値、Date、DateTime、FixedString、Enum、それらの型の Nullable、それらの型の Tuple) に制限されます。1 に設定すると、動的フィルタリングは可変長型にも適用されます。

設定可能な値:

• 0 — 無効。
• 1 — 有効。

​

use_uncompressed_cache

非圧縮ブロックのキャッシュを使用するかどうかを指定します。指定できる値は 0 または 1 です。デフォルトは 0 (無効) です。 非圧縮キャッシュ (MergeTree family のテーブルでのみ有効) を使用すると、多数の短いクエリを実行する際のレイテンシを大幅に低減し、スループットを向上させることができます。短いリクエストを高頻度で送信するユーザーには、この設定を有効にしてください。また、uncompressed_cache_size 設定パラメータ (設定ファイルでのみ設定可能) — 非圧縮キャッシュブロックのサイズ — にも注意してください。デフォルト値は 8 GiB です。非圧縮キャッシュは必要に応じて補完され、あまり使われないデータは自動的に削除されます。

ある程度大きなデータ量 (100 万行以上) を読み取るクエリでは、本当に小さなクエリ向けの領域を確保するため、非圧縮キャッシュは自動的に無効になります。つまり、use_uncompressed_cache は常に 1 に設定しておけます。

​

use_variant_as_common_type

引数の型に共通型がない場合に、if/multiIf/array/map 関数の結果型として Variant 型を使用できるようにします。

例:

SET use_variant_as_common_type = 1;
SELECT toTypeName(if(number % 2, number, range(number))) as variant_type FROM numbers(1);
SELECT if(number % 2, number, range(number)) as variant FROM numbers(5);

┌─variant_type───────────────────┐
│ Variant(Array(UInt64), UInt64) │
└────────────────────────────────┘
┌─variant───┐
│ []        │
│ 1         │
│ [0,1]     │
│ 3         │
│ [0,1,2,3] │
└───────────┘

SET use_variant_as_common_type = 1;
SELECT toTypeName(multiIf((number % 4) = 0, 42, (number % 4) = 1, [1, 2, 3], (number % 4) = 2, 'Hello, World!', NULL)) AS variant_type FROM numbers(1);
SELECT multiIf((number % 4) = 0, 42, (number % 4) = 1, [1, 2, 3], (number % 4) = 2, 'Hello, World!', NULL) AS variant FROM numbers(4);

─variant_type─────────────────────────┐
│ Variant(Array(UInt8), String, UInt8) │
└──────────────────────────────────────┘

┌─variant───────┐
│ 42            │
│ [1,2,3]       │
│ Hello, World! │
│ ᴺᵁᴸᴸ          │
└───────────────┘

SET use_variant_as_common_type = 1;
SELECT toTypeName(array(range(number), number, 'str_' || toString(number))) as array_of_variants_type from numbers(1);
SELECT array(range(number), number, 'str_' || toString(number)) as array_of_variants FROM numbers(3);

┌─array_of_variants_type────────────────────────┐
│ Array(Variant(Array(UInt64), String, UInt64)) │
└───────────────────────────────────────────────┘

┌─array_of_variants─┐
│ [[],0,'str_0']    │
│ [[0],1,'str_1']   │
│ [[0,1],2,'str_2'] │
└───────────────────┘

SET use_variant_as_common_type = 1;
SELECT toTypeName(map('a', range(number), 'b', number, 'c', 'str_' || toString(number))) as map_of_variants_type from numbers(1);
SELECT map('a', range(number), 'b', number, 'c', 'str_' || toString(number)) as map_of_variants FROM numbers(3);

┌─map_of_variants_type────────────────────────────────┐
│ Map(String, Variant(Array(UInt64), String, UInt64)) │
└─────────────────────────────────────────────────────┘

┌─map_of_variants───────────────┐
│ {'a':[],'b':0,'c':'str_0'}    │
│ {'a':[0],'b':1,'c':'str_1'}   │
│ {'a':[0,1],'b':2,'c':'str_2'} │
└───────────────────────────────┘

​

use_variant_default_implementation_for_comparisons

比較関数における Variant 型のデフォルト実装を有効または無効にします。

​

use_with_fill_by_sorting_prefix

ORDER BY 句で WITH FILL カラムに先行するカラムは、ソートプレフィックスを形成します。ソートプレフィックスの値が異なる行は、それぞれ独立して補完されます

​

validate_enum_literals_in_operators

有効にすると、IN、NOT IN、==、!= などの演算子内の enum リテラルを enum 型に対して検証し、そのリテラルが有効な enum 値でない場合は例外を発生させます。

​

validate_mutation_query

受け付ける前に mutation クエリを検証します。mutation はバックグラウンドで実行されるため、無効なクエリを実行すると mutation が停止したままになり、手動での対応が必要になります。

後方互換性のないバグに遭遇した場合にのみ、この設定を変更してください。

​

validate_polygons

ポリゴンが自己交差または自己接触している場合に、pointInPolygon 関数で例外をスローするかどうかを有効または無効にします。

設定可能な値:

• 0 — 例外のスローは無効です。pointInPolygon は無効なポリゴンを受け入れ、それに対して誤った結果を返す可能性があります。
• 1 — 例外のスローは有効です。

​

variant_throw_on_type_mismatch

デフォルト実装を使用して Variant カラムに関数を適用する際に、 実際の型がその関数と互換性のない行に対してどのように動作するかを制御します。

• true (デフォルト) — 例外をスローします。
• false — 代わりに、それらの行では NULL を返します。

​

vector_search_filter_strategy

ベクトル検索クエリに WHERE 句がある場合、この設定は、まずそれを評価する (pre-filtering) か、先にベクトル類似度索引を参照する (ポストフィルタリング) かを決定します。設定可能な値:

• ‘auto’ - ポストフィルタリング (正確な動作は今後変更される可能性があります) 。
• ‘postfilter’ - ベクトル類似度索引を使用して最近傍を特定し、その後でほかのフィルターを適用します
• ‘prefilter’ - まずほかのフィルターを評価し、その後で総当たり検索を実行して近傍を特定します。

​

vector_search_index_fetch_multiplier

別名: vector_search_postfilter_multiplier

ベクトル類似度索引から取得する最近傍の数を、この値倍にします。他の述語によるポストフィルタリング時、または設定 vector_search_with_rescoring = 1 の場合にのみ適用されます。

​

vector_search_with_rescoring

ClickHouse が、ベクトル類似度索引を使用するクエリに対して rescoring を実行するかどうかを指定します。 rescoring を行わない場合、ベクトル類似度索引は最適な一致を含む行を直接返します。 rescoring を行う場合は、行が granule レベルに拡張され、その granule 内のすべての行が再度チェックされます。 ほとんどの場合、rescoring による精度向上はわずかですが、ベクトル検索クエリのパフォーマンスは大きく低下します。 注: rescoring を行わず、かつ並列レプリカが有効な状態で実行されたクエリは、rescoring にフォールバックすることがあります。

​

wait_changes_become_visible_after_commit_mode

コミット済みの変更が最新のスナップショットで実際に見えるようになるまで待機します

​

wait_for_async_insert

true の場合は、非同期挿入の処理が完了するまで待機します

​

wait_for_async_insert_timeout

非同期挿入の処理完了を待機する際のタイムアウト

​

wait_for_part_commit_in_dependent_materialized_views

各 sink が、自身で書き込んだばかりのパーツを、自身に依存する materialized view のカスケードが実行される前にコミットするかどうかを制御します。これにより、JOIN を介してソースを再度読み込むカスケードで、その sink が書き込んだパーツを参照できます。

この保証は sink インスタンスごとに適用されます。同じ INSERT の他の sink スレッドによって書き込まれたパーツは、まだ見えない場合があります。この設定では、スレッド間のコミット順序は保証されません。

依存する materialized view がないテーブルへの INSERT には影響しません。

​

wait_for_window_view_fire_signal_timeout

イベント時間処理で window view の fire signal を待機する際のタイムアウト

​

webassembly_udf_max_fuel

WebAssembly UDF インスタンスの実行ごとの fuel の上限です。各 WebAssembly 命令は一定量の fuel を消費します。値はランタイムに渡される前に 1024 倍されるため、webassembly_udf_max_fuel = 1 はおよそ 1024 fuel 単位に相当します。有限の上限を設けない場合は 0 に設定します。これは、関数ごとの設定 webassembly_udf_enable_fuel が true の関数にのみ適用されます。これが既定値です。

​

webassembly_udf_max_input_block_size

1 つのブロックで WebAssembly UDF に渡される最大行数。0 に設定すると、すべての行が一度に処理されます。

​

webassembly_udf_max_instances

関数ごとに並列実行できる WebAssembly UDF インスタンスの最大数。

​

webassembly_udf_max_memory

各 WebAssembly UDF インスタンスに対する、バイト単位のメモリ制限。

​

window_view_clean_interval

window view の古くなったデータを解放するための、秒単位のクリーンアップ間隔。

​

window_view_heartbeat_interval

watchクエリが稼働中であることを示す、秒単位のハートビート間隔です。

​

workload

リソースへのアクセスに使用するワークロード名

​

write_full_path_in_iceberg_metadata

完全なパス (s3:// を含む) を Iceberg メタデータファイルに書き込みます。

​

write_through_distributed_cache

ClickHouse Cloud でのみ効果があります。分散キャッシュへの書き込みを許可します (S3 への書き込みも分散キャッシュ経由で行われます)

​

write_through_distributed_cache_buffer_size

ClickHouse Cloud でのみ有効です。ライトスルー分散キャッシュのバッファサイズを設定します。0 の場合は、分散キャッシュがない場合に使用されるバッファサイズが使われます。

​

zstd_window_log_max

ZSTD の最大ウィンドウログを指定できます (MergeTree family では使用されません)