セッション設定

すべての設定は、テーブル system.settings でも利用可能です。これらの設定は、source から自動生成されています。

add_http_cors_header​

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

additional_result_filter​

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

例

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

クエリ内のすべての集約関数を再記述し、-OrNull サフィックスを追加することを有効または無効にします。SQL 標準の互換性を保つために有効にしてください。 これは、分散クエリに対する一貫した結果を得るために、クエリの再記述を通じて実装されています（count_distinct_implementation 設定と類似）。

可能な値：

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

例

以下の集約関数を含むクエリを考えます：

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​

主キーの順序で集約中に蓄積されるブロックの最大サイズ（バイト単位）です。ブロックサイズが小さいほど、集約の最終マージ段階をより多く並行処理できます。

aggregation_memory_efficient_merge_threads​

メモリー効率モードで中間集約結果をマージするために使用されるスレッド数。大きくなるほど、より多くのメモリが消費されます。0 は「max_threads」と同じです。

allow_aggregate_partitions_independently​

パーティションキーがグループ化キーに適合する場合に、別々のスレッドでのパーティションの独立した集約を有効にします。パーティションの数がコアの数に近く、パーティションがほぼ同じサイズである場合に有益です。

allow_archive_path_syntax​

ファイル/S3 エンジン/テーブル関数は、アーカイブが正しい拡張子を持っている場合、パスを <archive> :: <file> として解析します。

allow_asynchronous_read_from_io_pool_for_merge_tree​

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

allow_changing_replica_until_first_data_packet​

有効にすると、ヘッジ要求の中で、最初のデータパケットを受信するまで新しい接続を開始でき、すでにいくらかの進捗があっても構いません（ただし、進捗が receive_data_timeout タイムアウトで更新されていない場合）。そうでない場合は、最初の進捗を上げた後、レプリカの変更が無効になります。

allow_create_index_without_type​

TYPE なしで CREATE INDEX クエリを許可します。クエリは無視されます。SQL 互換性テストのために作成されました。

allow_custom_error_code_in_throwif​

function 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 キーで動的型を使用することを許可します。互換性のために追加されました。他の型との比較が予期しない結果をもたらす可能性があるため、JOIN キーで動的型を使用することは推奨されません。

allow_execute_multiif_columnar​

multiIf 関数を列指向で実行することを許可します。

allow_experimental_analyzer​

新しいクエリアナライザーを許可します。

allow_experimental_codecs​

true に設定されている場合、実験的な圧縮コーデックを指定することを許可します（ただし、これらはまだ存在せず、このオプションは何もしません）。

allow_experimental_correlated_subqueries​

相関サブクエリを実行することを許可します。

allow_experimental_database_glue_catalog​

カタログタイプが 'glue' の実験的なデータベースエンジン DataLakeCatalog を許可します。

allow_experimental_database_hms_catalog​

カタログタイプが 'hms' の実験的なデータベースエンジン DataLakeCatalog を許可します。

allow_experimental_database_iceberg​

カタログタイプが 'iceberg' の実験的なデータベースエンジン DataLakeCatalog を許可します。

allow_experimental_database_materialized_postgresql​

Engine=MaterializedPostgreSQL(...) でデータベースを作成することを許可します。

allow_experimental_database_unity_catalog​

カタログタイプが 'unity' の実験的なデータベースエンジン DataLakeCatalog を許可します。

allow_experimental_delta_kernel_rs​

実験的な delta-kernel-rs 実装を許可します。

allow_experimental_delta_lake_writes​

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

allow_experimental_full_text_index​

true に設定すると、実験的なテキストインデックスを使用することを許可します。

allow_experimental_funnel_functions​

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

allow_experimental_hash_functions​

実験的なハッシュ関数を有効にします。

allow_experimental_iceberg_compaction​

iceberg テーブルで「OPTIMIZE」を明示的に使用することを許可します。

allow_experimental_insert_into_iceberg​

iceberg に insert クエリを実行することを許可します。

allow_experimental_join_right_table_sorting​

true に設定されている場合、join_to_sort_minimum_perkey_rows および join_to_sort_maximum_table_rows の条件が満たされる際、パフォーマンス向上のために右テーブルをキーで再配置します。

allow_experimental_kafka_offsets_storage_in_keeper​

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

allow_experimental_kusto_dialect​

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

allow_experimental_live_view​

廃止された LIVE VIEW の作成を許可します。

可能な値：

• 0 — ライブビューでの作業を無効にします。
• 1 — ライブビューでの作業を有効にします。

allow_experimental_materialized_postgresql_table​

MaterializedPostgreSQL テーブルエンジンを使用することを許可します。デフォルトでは無効です。この機能は実験的です。

allow_experimental_nlp_functions​

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

allow_experimental_object_type​

廃止された Object データ型を許可します。

allow_experimental_parallel_reading_from_replicas​

SELECT クエリの実行のために、各シャードから max_parallel_replicas の数のレプリカを使用します。読み取りは動的に並行処理され、調整されます。0 - 無効、1 - 有効、失敗時は静かに無効、2 - 有効、失敗時は例外をスローします。

allow_experimental_prql_dialect​

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

allow_experimental_qbit_type​

QBit データ型の作成を許可します。

allow_experimental_query_deduplication​

パート UUID に基づく SELECT クエリ用の実験的なデータ重複排除を許可します。

allow_experimental_statistics​

統計を持つカラムを定義し、統計を操作することを許可します。

allow_experimental_time_series_aggregate_functions​

Prometheus スタイルの時系列再サンプリング、レート、差分計算のための実験的な timeSeries* 集約関数を許可します。

allow_experimental_time_series_table​

TimeSeries テーブルエンジンでテーブルを作成することを許可します。可能な値：

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

allow_experimental_time_time64_type​

Time および Time64 データ型の作成を許可します。

allow_experimental_window_view​

WINDOW VIEW を有効にします。まだ十分に成熟していません。

allow_experimental_ytsaurus_dictionary_source​

YTsaurus との統合のための実験的な辞書ソースです。

allow_experimental_ytsaurus_table_engine​

YTsaurus との統合のための実験的なテーブルエンジンです。

allow_experimental_ytsaurus_table_function​

YTsaurus との統合のための実験的なテーブルエンジンです。

allow_general_join_planning​

より複雑な条件を処理できる一般的な結合計画アルゴリズムを許可しますが、ハッシュ結合のみで機能します。ハッシュ結合が無効な場合、この設定の値に関係なく、通常の結合計画アルゴリズムが使用されます。

allow_get_client_http_header​

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

allow_hyperscan​

Hyperscan ライブラリを使用する関数を許可します。コンパイル時間が長くなる可能性があるため、無効にすることをお勧めします。

allow_introspection_functions​

クエリプロファイリングのための イントロスペクション関数 を有効または無効にします。

可能な値：

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

関連情報

• Sampling Query Profiler
• システムテーブル trace_log

allow_materialized_view_with_bad_select​

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

allow_named_collection_override_by_default​

デフォルトで名前付きコレクションのフィールドの上書きを許可します。

allow_non_metadata_alters​

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

allow_nonconst_timezone_arguments​

toTimeZone()、fromUnixTimestamp*()、snowflakeToDateTime*() などのいくつかの時間関連関数で非定数のタイムゾーン引数の使用を許可します。 この設定は互換性のためのもので、ClickHouse ではタイムゾーンがデータ型のプロパティ、すなわちカラムのプロパティです。 この設定を有効にすると、カラム内の異なる値が異なるタイムゾーンを持つという誤解を招くことがあります。 したがって、この設定は有効にしないでください。

allow_nondeterministic_mutations​

ユーザーレベル設定として、replicated テーブルで dictGet などの非決定的関数を利用する変更を許可します。

たとえば、辞書はノード間で同期されていない可能性があるため、これらから値を引き出す変更は、デフォルトで replicated テーブルでは禁止されています。この設定を有効にすると、この動作が許可され、ユーザーが使用するデータがすべてのノードで同期されていることを保証する責任が生じます。

例

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

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

    <!-- ... -->

</profiles>

allow_nondeterministic_optimize_skip_unused_shards​

シャーディングキーで非決定的（rand や dictGet など、後者には更新に関するいくつかの注意点があります）関数を許可します。

可能な値：

• 0 — 不許可。
• 1 — 許可。

allow_not_comparable_types_in_comparison_functions​

equal/less/greater/etc のような比較関数で比較できない型（JSON/Object/AggregateFunction など）の使用を許可または制限します。

allow_not_comparable_types_in_order_by​

ORDER BY キーで比較できない型（JSON/Object/AggregateFunction など）の使用を許可または制限します。

allow_prefetched_read_pool_for_local_filesystem​

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

allow_prefetched_read_pool_for_remote_filesystem​

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

allow_push_predicate_ast_for_distributed_subqueries​

分散サブクエリに対して AST レベルで述語をプッシュすることを許可します。

allow_push_predicate_when_subquery_contains_with​

サブクエリが WITH 句を含む場合に、述語をプッシュすることを許可します。

allow_reorder_prewhere_conditions​

WHERE から PREWHERE に条件を移動するとき、フィルタリングを最適化するためにそれらを再配置することを許可します。

allow_settings_after_format_in_insert​

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

例：

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_statistics_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 では各行に数値インデックスを保存するため、次のようになります：

• ディスクスペースの使用量が増加する可能性があります。
• 辞書サイズに応じて、RAM 消費が増加する可能性があります。
• 追加のコーディング/エンコーディング操作により、一部の関数が遅くなることがあります。

MergeTree-エンジンテーブルのマージ時間は、上記のすべての理由により増加する可能性があります。

可能な値：

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

allow_suspicious_primary_key​

疑わしい PRIMARY KEY/ORDER BY を MergeTree に許可します（すなわち、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 型を指定することを許可します。この設定を有効にすることで、類似の型を持つ値の操作時にあいまいさが生じる可能性があります。

allow_unrestricted_reads_from_keeper​

システム.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​

レプリカでの ALTER、OPTIMIZE、または TRUNCATE クエリの実行待機を設定することを許可します。

可能な値：

• 0 — 待機しない。
• 1 — 自身の実行を待機。
• 2 — すべてを待機。

クラウドデフォルト値： 1。

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​

ネストされた要素に複合識別子を追加することを許可します。これはクエリ結果を変更するため、互換性設定です。無効にすると、SELECT a.b.c FROM table ARRAY JOIN a は動作せず、SELECT a FROM table は Nested a 結果に a.b.c カラムを含みません。

analyzer_compatibility_join_using_top_level_identifier​

JOIN USING で識別子を投影から解決するよう強制します（例えば、SELECT a + 1 AS b FROM t1 JOIN t2 USING (b) では、t1.a + 1 = t2.b で結合が行われ、t1.b = t2.b にはなりません）。

any_join_distinct_right_table_keys​

ANY INNER|LEFT JOIN 操作における従来の ClickHouse サーバーの動作を有効にします。

レガシーな動作が有効な場合：

• t1 ANY LEFT JOIN t2 と t2 ANY RIGHT JOIN t1 操作の結果は等しくなく、ClickHouse は左から右のテーブルキーのマッピングに多対1のロジックを使用します。
• ANY INNER JOIN 操作の結果は、SEMI LEFT JOIN 操作と同じく、左テーブルのすべての行を含みます。

レガシーな動作が無効な場合：

• t1 ANY LEFT JOIN t2 と t2 ANY RIGHT JOIN t1 操作の結果は等しく、ClickHouse は ANY RIGHT JOIN 操作に多対1のキーのマッピングを提供するロジックを使用します。
• ANY INNER JOIN 操作の結果は、左テーブルと右テーブルのそれぞれのキーに対して 1 行を含みます。

可能な値：

• 0 — レガシー動作は無効です。
• 1 — レガシー動作は有効です。

参照：

• JOIN の厳密性

apply_deleted_mask​

軽量 DELETE で削除された行をフィルタリングすることを有効にします。無効にすると、クエリはこれらの行を読み取ることができます。これはデバッグおよび「未削除」シナリオに便利です。

apply_mutations_on_fly​

true の場合、データパートにマテリアライズされていない変更（UPDATE および DELETE）が SELECT に適用されます。

apply_patch_parts​

true の場合、パッチパーツ（軽量更新を表す）が SELECT に適用されます。

apply_patch_parts_join_cache_buckets​

JOIN モードでパッチパーツを適用するための一時キャッシュ内のバケット数です。

apply_settings_from_server​

クライアントがサーバーから設定を受け入れるべきかどうか。

これはクライアント側の操作にのみ影響し、特に INSERT 入力データの解析やクエリ結果のフォーマットに影響します。クエリの実行の大部分はサーバー上で行われ、この設定の影響はありません。

通常、この設定はユーザープロファイル（users.xml または ALTER USER などのクエリ内）で設定されるべきであり、クライアントを通じて（クライアントコマンドライン引数、SET クエリ、または SELECT クエリの SETTINGS セクション）で変更することは推奨されません。クライアントを通じて false に変更できますが、true に変更することはできません（ユーザープロファイルに apply_settings_from_server = false が設定されている場合、サーバーは設定を送信しません）。

初期の段階で（24.12）、サーバー設定 (send_settings_to_client) がありましたが、後に使い勝手向上のためにこのクライアント設定に置き換えられました。

asterisk_include_alias_columns​

ワイルドカードクエリ（SELECT *）のために ALIAS カラムを含めることを許可します。

可能な値：

• 0 - 無効
• 1 - 有効

asterisk_include_materialized_columns​

ワイルドカードクエリ（SELECT *）のために MATERIALIZED カラムを含めることを許可します。

可能な値：

• 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_min_ms​

async_insert_use_adaptive_busy_timeout が有効になっている場合、最初のデータが出現してからクエリごとに収集したデータをダンプする前の最小待機時間です。また、適応アルゴリズムの初期値としても機能します。

async_insert_deduplicate​

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

async_insert_max_data_size​

挿入される前のクエリごとに収集された未解析データの最大サイズ（バイト単位）です。

async_insert_max_query_number​

挿入される前の最大挿入クエリ数です。設定 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​

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

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

azure_allow_parallel_part_upload​

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

azure_check_objects_after_upload​

アップロードが成功したことを確認するために、Azure Blob ストレージ内の各アップロード対象オブジェクトをチェックします。

azure_connect_timeout_ms​

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

azure_create_new_file_on_insert​

Azure エンジンテーブルに対する各挿入時に新しいファイルを作成するかどうかを有効または無効にします。

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​

リクエスト毎秒の制限に達する前に同時に発行できるリクエストの最大数。デフォルト（0）は azure_max_get_rps と等しいです。

azure_max_get_rps​

スロットリング前の Azure GET リクエスト毎秒の制限です。ゼロは無制限を意味します。

azure_max_inflight_parts_for_one_file​

マルチパートアップロードリクエストにおいて同時にロードされた部分の最大数です。0 は無制限を意味します。

azure_max_put_burst​

リクエスト毎秒の制限に達する前に同時に発行できるリクエストの最大数。デフォルト（0）は azure_max_put_rps と等しいです。

azure_max_put_rps​

スロットリング前の Azure PUT リクエスト毎秒の制限です。ゼロは無制限を意味します。

azure_max_redirects​

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

azure_max_single_part_copy_size​

Azure Blob ストレージへの単一パートコピーを使用してコピーするオブジェクトの最大サイズです。

azure_max_single_part_upload_size​

Azure Blob ストレージへの単一パートアップロードを使用してアップロードするオブジェクトの最大サイズです。

azure_max_single_read_retries​

単一の Azure Blob ストレージ読み取り中にリトライする最大回数です。

azure_max_unexpected_write_error_retries​

Azure Blob ストレージの書き込み中に予期しないエラーが発生した場合のリトライ最大回数です。

azure_max_upload_part_size​

Azure Blob ストレージへのマルチパートアップロード中にアップロードするパーツの最大サイズです。

azure_min_upload_part_size​

Azure Blob ストレージへのマルチパートアップロード中にアップロードするパーツの最小サイズです。

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

Azure SDK に対する ClickHouse ネイティブ HTTP クライアントを使用します。

azure_skip_empty_files​

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

可能な値：

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

azure_strict_upload_part_size​

Azure Blob ストレージへのマルチパートアップロード中にアップロードするパーツの正確なサイズです。

azure_throw_on_zero_files_match​

グロブ展開ルールに従って一致するファイルがゼロの場合にエラーをスローします。

可能な値：

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

azure_truncate_on_insert​

Azure エンジンテーブルに挿入する前に切り詰めることを有効または無効にします。

azure_upload_part_size_multiply_factor​

Azure Blob ストレージに単一の書き込みからアップロードされた azure_multiply_parts_count_threshold 部分ごとに azure_min_upload_part_size をこの係数で掛けます。

azure_upload_part_size_multiply_parts_count_threshold​

この数のパーツが Azure Blob ストレージにアップロードされるたびに、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​

バックアップオンクラスターまたはリストアオンクラスター操作中にホストが一定の時間内に ZooKeeper におけるそのエピhemeral ‘alive’ ノードを再作成しない場合、全体のバックアップまたはリストアは失敗と見なされます。この値は、ホストが障害後に ZooKeeper に再接続するための合理的な時間よりも大きくする必要があります。ゼロは無制限を意味します。

backup_restore_finish_timeout_after_error_sec​

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

backup_restore_keeper_fault_injection_probability​

バックアップまたはリストア中の Keeper リクエストに対する障害注入の近似確率です。有効な値は [0.0f, 1.0f] の範囲です。

backup_restore_keeper_fault_injection_seed​

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

backup_restore_keeper_max_retries​

バックアップまたはリストア操作の最中に行われる [Zoo]Keeper 操作の最大リトライ数です。この数は、全体の操作が一時的な [Zoo]Keeper 障害のために失敗しないように十分大きい必要があります。

backup_restore_keeper_max_retries_while_handling_error​

バックアップオンクラスターまたはリストアオンクラスター操作中にエラーを処理している間の [Zoo]Keeper 操作の最大リトライ数です。

backup_restore_keeper_max_retries_while_initializing​

バックアップオンクラスターまたはリストアオンクラスター操作の初期化中に [Zoo]Keeper 操作の最大リトライ数です。

backup_restore_keeper_retry_initial_backoff_ms​

バックアップまたはリストア中の [Zoo]Keeper 操作の初期バックオフタイムアウトです。

backup_restore_keeper_retry_max_backoff_ms​

バックアップまたはリストア中の [Zoo]Keeper 操作の最大バックオフタイムアウトです。

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 のリトライバックオフ遅延に適用されるジッターファクターです。計算されたバックオフ遅延は、範囲 [1.0, 1.0 + jitter] のランダム因子で掛け算され、最大 backup_restore_s3_retry_max_backoff_ms まで適用されます。[0.0, 1.0] の範囲である必要があります。

backup_restore_s3_retry_max_backoff_ms​

バックアップおよびリストア操作中のリトライ間の最大遅延（ミリ秒単位）です。

cache_warmer_threads​

ClickHouse Cloud でのみ影響します。 cache_populated_by_fetch が有効になっているときに、新しいデータパーツをファイルキャッシュに投機的にダウンロードするためのバックグラウンドスレッドの数です。ゼロで無効にします。

calculate_text_stack_trace​

クエリ実行中に例外が発生した場合にテキストスタックトレースを計算します。これはデフォルトです。多量の誤ったクエリが実行される際のファジングテストでは、シンボルの検索が遅延する可能性があります。通常の場合、このオプションを無効にすべきではありません。

cancel_http_readonly_queries_on_client_close​

クライアントが応答を待たずに接続を閉じたときに、HTTP の読み取り専用クエリ（例： SELECT）をキャンセルします。

クラウドのデフォルト値：0。

cast_ipv4_ipv6_default_on_conversion_error​

CAST 演算子を IPv4 に、CAST 演算子を IPV6 型に、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​

文字列から日付と時刻へのキャスト中に、テキスト表現のパーサーを選択できるようにします。

可能な値：

• '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​

文字列から動的な変換中に型推論を使用します。

cast_string_to_variant_use_inference​

文字列からバリアント変換中に型推論を使用します。

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 ファミリーのテーブルにのみ適用されます。他のテーブルエンジンやネットワーク経由でデータを受信する際には常にチェックサムが検証されます。

cloud_mode​

クラウドモードです。

cloud_mode_database_engine​

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

cloud_mode_engine​

クラウドで許可されるエンジンファミリー。

• 0 - すべてを許可
• 1 - *ReplicatedMergeTree を使用するように DDL を書き換えます。
• 2 - SharedMergeTree を使用するように DDL を書き換えます。
• 3 - 明示的に渡されたリモートディスクが指定されていない限り、SharedMergeTree を使用するように DDL を書き換えます。

UInt64 パブリック部分の最小化のため。

cluster_for_parallel_replicas​

現在のサーバーが位置するシャードのクラスタです。

cluster_function_process_archive_on_multiple_nodes​

true に設定すると、クラスタ機能でのアーカイブ処理のパフォーマンスが向上します。クラスタ機能での以前のバージョンでのアーカイブ中に相互運用性を維持するため、 false に設定する必要があります。

collect_hash_table_stats_during_aggregation​

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

collect_hash_table_stats_during_joins​

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

compatibility​

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

設定が非デフォルト値に設定されている場合、それらの設定が尊重されます（変更されていない設定のみにcompatibility 設定が影響します）。

この設定は、文字列形式の ClickHouse バージョン番号（例： 22.3 、 22.8 ）を取ります。空の値はこの設定が無効であることを意味します。

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

compatibility_ignore_auto_increment_in_create_table​

true に設定されている場合、カラム宣言内の AUTO_INCREMENT キーワードを無視します。これにより、MySQL からの移行が簡素化されます。

compatibility_ignore_collation_in_create_table​

テーブル作成時の照合を無視する互換性です。

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' セクションが使用されている場合、分散テーブルエンジンのリモートサーバーへの接続の際のミリ秒単位のタイムアウトです。接続に失敗した場合、さまざまなレプリカへの接続を試みます。

connect_timeout_with_failover_secure_ms​

最初の健全なレプリカを選択する際の接続タイムアウト（安全な接続用）です。

connection_pool_max_wait_ms​

接続プールが満杯のときの接続待機時間（ミリ秒単位）です。

可能な値：

• 正の整数。
• 0 — 無限のタイムアウト。

connections_with_failover_max_tries​

分散テーブルエンジンの各レプリカへの接続試行の最大回数です。

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

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

count_distinct_implementation​

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

可能な値：

• uniq
• uniqCombined
• uniqCombined64
• uniqHLL12
• uniqExact

count_distinct_optimization​

重複をカウントするをグループ化のサブクエリへ書き換えます。

count_matches_stop_at_empty_match​

countMatches 関数のパターンの一致がゼロ長になった場合にカウントを停止します。

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 に作成後、テーブル作成中の障害注入の確率です。

create_table_empty_primary_key_by_default​

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

cross_join_min_bytes_to_compress​

CROSS JOIN で圧縮するためのブロックの最小サイズです。ゼロの値はこのしきい値を無効にします。このブロックは、行数またはバイト数のいずれかのしきい値が達成されたときに圧縮されます。

cross_join_min_rows_to_compress​

CROSS JOIN でブロックを圧縮するための最小行数です。ゼロの値はこのしきい値を無効にします。このブロックは、行数またはバイト数のいずれかのしきい値が達成されたときに圧縮されます。

data_type_default_nullable​

明示的修飾子 NULL または NOT NULL のないデータ型を列定義内で Nullable として扱います。

可能な値：

• 1 — 列定義内のデータ型はデフォルトで Nullable として設定されます。
• 0 — 列定義内のデータ型はデフォルトで Nullable ではなく設定されます。

database_atomic_wait_for_drop_and_detach_synchronously​

すべての DROP および DETACH クエリに SYNC モディファイアを追加します。

可能な値：

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

database_replicated_allow_explicit_uuid​

0 - レプリケートされたデータベースのテーブルのために UUID を明示的に指定することを許可しません。1 - 許可。2 - 許可しますが、指定した UUID を無視して代わりにランダムな UUID を生成します。

database_replicated_allow_heavy_create​

レプリケーションデータベースエンジンで長時間実行される DDL クエリ（CREATE AS SELECT や POPULATE）を許可します。ただし、これにより DDL キューが長時間ブロックされる可能性があります。

database_replicated_allow_only_replicated_engine​

レプリケーションエンジンを持つデータベースで、レプリケーションテーブルのみを作成できるようにします。

database_replicated_allow_replicated_engine_arguments​

0 - レプリケートされたデータベース内の *MergeTree テーブルの ZooKeeper パスとレプリカ名を明示的に指定することを許可しません。1 - 許可。2 - 許可しますが、指定したパスを無視してデフォルトを使用します。3 - 許可し、警告を記録しません。

database_replicated_always_detach_permanently​

データベースエンジンがレプリケートされている場合、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 — 無限。

decimal_check_overflow​

10進数の算術/比較演算のオーバーフローをチェックします。

deduplicate_blocks_in_dependent_materialized_views​

Replicated* テーブルからデータを受け取る物化ビューに対する重複排除チェックを有効または無効にします。

可能な値：

0 — 無効。 1 — 有効。

有効にすると、ClickHouse は Replicated* テーブルに依存する物化ビューのブロックの重複を排除します。この設定は、挿入操作が失敗により再試行される場合に、物化ビューが重複データを含まないことを保証するのに役立ちます。

関連情報

• IN 演算子の NULL 処理

default_materialized_view_sql_security​

物化ビューを作成する際の SQL SECURITY オプションのデフォルト値を設定できます。 SQL セキュリティについての詳細。

デフォルト値は DEFINER です。

default_max_bytes_in_join​

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

default_normal_view_sql_security​

通常のビューを作成する際のデフォルトの SQL SECURITY オプションを設定します。 SQL セキュリティについての詳細。

デフォルト値は INVOKER です。

default_table_engine​

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

可能な値：

• 有効なテーブルエンジン名を示す文字列。

クラウドのデフォルト値： 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セキュリティの詳細。

デフォルト値は CURRENT_USER です。

delta_lake_enable_engine_predicate​

デルタカーネルの内部データプルーニングを有効にします。

delta_lake_enable_expression_visitor_logging​

デルタレイクの式ビジターのテストレベルのログを有効にします。これらのログは、テストログとしては非常に冗長になる可能性があります。

delta_lake_insert_max_bytes_in_data_file​

デルタレイクに挿入されたデータファイルのバイト数の制限を定義します。

delta_lake_insert_max_rows_in_data_file​

デルタレイクに挿入されたデータファイルの行数の制限を定義します。

delta_lake_log_metadata​

システムテーブルにデルタレイクメタデータファイルをログに記録することを有効にします。

delta_lake_snapshot_version​

読み取るデルタレイクスナップショットのバージョン。値 -1 は最新バージョンを読み取ることを意味します（値 0 は有効なスナップショットバージョンです）。

delta_lake_throw_on_engine_predicate_error​

デルタカーネルでスキャン述語を分析中にエラーが発生した場合に例外をスローすることを有効にします。

describe_compact_output​

true の場合、DESCRIBE クエリの結果にカラム名と型のみを含めます。

describe_extend_object_types​

DESCRIBE クエリでのオブジェクト型のカラムの具体的な型を推定します。

describe_include_subcolumns​

DESCRIBE クエリにおいてサブカラムを記述することを有効にします。たとえば、Tuple のメンバーや、Map、Nullable または Array データ型のサブカラムです。

可能な値：

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

例

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

describe_include_virtual_columns​

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

dialect​

クエリを解析するために使用される方言。

dictionary_validate_primary_key_type​

辞書の主キータイプを検証します。デフォルトでは、単純なレイアウトに対して ID タイプは UInt64 に暗黙的に変換されます。

distinct_overflow_mode​

データ量が限界を超えた場合に何が起こるかを設定します。

可能な値：

• throw: 例外をスローします（デフォルト）。
• break: クエリの実行を停止し、ソースデータが切れたかのように部分結果を返します。

distributed_aggregation_memory_efficient​

メモリ節約モードの分散集計が有効になっています。

distributed_background_insert_batch​

挿入データをバッチで送信することを有効または無効にします。

バッチ送信が有効になっている場合、Distributed テーブルエンジンは、挿入データの複数のファイルを一度の操作で送信し、別々に送信する代わりに、より効率的にクラスターのパフォーマンスを向上させます。

可能な値：

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

distributed_background_insert_max_sleep_time_ms​

データを送信するために Distributed テーブルエンジンが使用できる最大インターバル。これは、distributed_background_insert_sleep_time_ms 設定で設定されたインターバルの指数的成長を制限します。

可能な値：

• 正の整数ミリ秒。

distributed_background_insert_sleep_time_ms​

データを送信するための Distributed テーブルエンジンの基準インターバル。このインターバルは、エラーが発生した場合に指数的に増加します。

可能な値：

• 正の整数ミリ秒。

distributed_background_insert_split_batch_on_failure​

失敗時のバッチ分割を有効または無効にします。

特定のバッチをリモートシャードに送信する際に失敗する場合があります。これは、後続の複雑なパイプライン（例：MATERIALIZED VIEW で GROUP BY）による Memory limit exceeded エラーなどが原因です。この場合、再試行しても助けにはならず（テーブルの分散送信が停止するため）、そのバッチからファイルを一つずつ送信することでINSERTに成功する可能性があります。

したがって、この設定を 1 にすると失敗したバッチのためにバッチ処理を無効にします（つまり、失敗したバッチに対して distributed_background_insert_batch を一時的に無効にします）。

可能な値：

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

distributed_background_insert_timeout​

分散に対する挿入クエリのタイムアウト。insert_distributed_sync が有効な場合のみ使用されます。ゼロ値はタイムアウトがないことを意味します。

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_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_log_mode​

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

distributed_cache_max_unacked_inflight_packets​

ClickHouse Cloud でのみ有効です。単一の分散キャッシュ読み取りリクエスト内の未確認のフライトパケットの最大数。

distributed_cache_min_bytes_for_seek​

ClickHouse Cloud でのみ有効です。分散キャッシュでシークを実行するための最小バイト数。

distributed_cache_pool_behaviour_on_limit​

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

distributed_cache_prefer_bigger_buffer_size​

ClickHouse Cloud でのみ有効です。distributed cache 用の 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 でのみ有効です。分散キャッシュからのレスポンスを受信するための待機時間（ミリ秒）。

distributed_cache_throw_on_error​

ClickHouse Cloud でのみ有効です。分散キャッシュとの通信中に発生した例外または分散キャッシュから受信した例外を再スローします。その他の場合、エラーで分散キャッシュをスキップします。

distributed_cache_wait_connection_from_pool_milliseconds​

ClickHouse Cloud でのみ有効です。distributed_cache_pool_behaviour_on_limit が wait の場合、接続プールから接続を受け取るための待機時間（ミリ秒）。

distributed_connections_pool_size​

単一の Distributed テーブルに対してリモートサーバーとの同時接続の最大数。クラスター内のサーバーの数以上の値に設定することをお勧めします。

distributed_ddl_entry_format_version​

分散DDL (ON CLUSTER) クエリの互換性バージョン。

distributed_ddl_output_mode​

分散DDLクエリ結果の形式を設定します。

可能な値：

• throw — クエリが完了したすべてのホストに対するクエリ実行ステータスを持つ結果セットを返します。いくつかのホストでクエリが失敗した場合、最初の例外を再スローします。一部のホストでクエリがまだ完了していない場合、distributed_ddl_task_timeout を超えると TIMEOUT_EXCEEDED 例外をスローします。
• none — throw と似ていますが、分散DDLクエリは結果セットを返しません。
• null_status_on_timeout — 対応するホストでクエリが完了していない場合は、結果セットのいくつかの行に 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 データベースの非アクティブレプリカを待機しません。

クラウドのデフォルト値: throw。

distributed_ddl_task_timeout​

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

可能な値：

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

distributed_foreground_insert​

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

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

可能な値：

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

クラウドのデフォルト値: 0。

こちらもご覧ください

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

distributed_group_by_no_merge​

分散クエリ処理のために異なるサーバーからの集計状態をマージしないでください。これは、異なるシャードに異なるキーがあることが確実である場合に使用できます。

可能な値：

• 0 — 無効（最終クエリ処理はイニシエーターのノードで行われます）。
• 1 - 分散クエリ処理のために異なるサーバーから集計状態をマージしません（クエリはシャードで完全に処理され、イニシエーターはデータをプロキシするだけです）。
• 2 - 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_insert_skip_read_only_replicas​

分散への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' - ネットワーク経由でのデータ交換を行います。

distributed_plan_force_shuffle_aggregation​

分散クエリプランにおいて部分集計 + マージの代わりにシャッフル集計戦略を使用します。

distributed_plan_max_rows_to_broadcast​

分散クエリプランにおいてシャッフルジョインの代わりにブロードキャストジョインを使用する最大行数。

distributed_plan_optimize_exchanges​

分散クエリプランにおいて不必要な交換を削除します。デバッグのためにこれを無効にしてください。

distributed_product_mode​

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

ClickHouse は、クエリが分散テーブルの積である場合、つまり、分散テーブルに対するクエリが分散テーブルの非GLOBALサブクエリを含む場合にこの設定を適用します。

制限事項：

• IN および JOIN サブクエリにのみ適用されます。
• FROM セクションが複数のシャードを含む分散テーブルを使用している場合にのみ適用されます。
• サブクエリが複数のシャードを含む分散テーブルに関係する場合。
• テーブル値の remote 関数に対しては使用されません。

可能な値：

• deny — デフォルト値。これらのタイプのサブクエリの使用を禁止します（"Double-distributed in/JOIN subqueries is denied" という例外が返されます）。
• local — サブクエリのデータベースとテーブルを送信先のサーバー（シャード）用のローカルなものに置き換えます（通常の IN/JOIN を残します）。
• global — IN/JOIN クエリを GLOBAL IN/GLOBAL JOIN に置き換えます。
• allow — これらのタイプのサブクエリの使用を許可します。

distributed_push_down_limit​

分散クエリの各シャードに対して LIMIT の適用を有効または無効にします。

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

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

21.9バージョン以降、distributed_push_down_limit は、不正確な結果を取得できないように変更されます。この設定は、少なくとも次の条件の1つが満たされた場合のみクエリ実行を変更します：

• 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

各レプリカのエラー数はこの値に制限され、単一のレプリカが過剰なエラーを蓄積するのを防ぎます。

こちらもご覧ください：

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

distributed_replica_error_half_life​

• タイプ: 秒
• デフォルト値: 60秒

分散テーブル内のエラーがゼロに戻る速さを制御します。レプリカが一定時間利用できず、5つのエラーが蓄積され、distributed_replica_error_half_life が 1 秒に設定されている場合、最後のエラーから 3 秒後にレプリカは正常と見なされます。

こちらもご覧ください：

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

distributed_replica_max_ignored_errors​

• タイプ: unsigned int
• デフォルト値: 0

レプリカを選択する際に無視されるエラーの数（load_balancing アルゴリズムに従う）。

こちらもご覧ください：

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

do_not_merge_across_partitions_select_final​

SELECT FINAL でパーツを1つのパーティション内だけでマージします。

empty_result_for_aggregation_by_constant_keys_on_empty_set​

空のセットでの定数キーによる集計時に空の結果を返します。

empty_result_for_aggregation_by_empty_set​

空のセットでキーなしで集計時に空の結果を返します。

enable_adaptive_memory_spill_scheduler​

外部ストレージにデータを適応的にスピルするためのトリガープロセッサ。グレースジョインが現在サポートされています。

enable_add_distinct_to_in_subqueries​

IN サブクエリで DISTINCT を有効にします。これはトレードオフ設定です：これを有効にすると、分散INサブクエリの転送される一時テーブルのサイズを大幅に削減でき、シャード間のデータ転送を大幅に高速化することができます。ただし、この設定を有効にすると、各ノードでの追加のマージ作業（DISTINCT）が必要になります。ネットワーク転送がボトルネックの場合や、追加のマージコストが受け入れられる場合にこの設定を使用してください。

enable_blob_storage_log​

blobストレージ操作に関する情報を system.blob_storage_log テーブルに書き込みます。

enable_deflate_qpl_codec​

オンにすると、DEFLATE_QPL コーデックを使用してカラムを圧縮できるようになります。

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

リモートファイルシステム用のキャッシュを使用します。この設定はディスクのキャッシュをオン/オフするものではなく（ディスク設定を介して行う必要があります）、意図しないクエリに対してキャッシュをバイパスすることを許可します。

enable_filesystem_cache_log​

各クエリに対してファイルシステムキャッシングログを記録できるようにします。

enable_filesystem_cache_on_write_operations​

write-through キャッシュを有効または無効にします。false に設定すると、書き込み操作に対する write-through キャッシュが無効になります。true に設定すると、サーバー設定のキャッシュディスク構成セクションで cache_on_write_operations がオンの場合、write-through キャッシュが有効になります。 詳細については、"ローカルキャッシュの使用"を参照してください。

enable_filesystem_read_prefetches_log​

クエリ中に system.filesystem の prefetch_log にログを記録します。これはテストまたはデバッグのためにのみ使用し、デフォルトでオンにしておくことは推奨されません。

enable_global_with_statement​

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

enable_hdfs_pread​

HDFSファイルに対して pread を有効または無効にします。デフォルトでは hdfsPread が使用されます。無効にすると、hdfsRead と hdfsSeek が使用されて HDFSファイルが読み取られます。

enable_http_compression​

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

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

可能な値：

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

enable_job_stack_trace​

例外に結果するジョブクリエーターのスタックトレースを出力します。パフォーマンスのオーバーヘッドを避けるためにデフォルトで無効になっています。

enable_join_runtime_filters​

右側からランタイムで収集された JOIN キーのセットによって左側をフィルタリングします。

enable_lightweight_delete​

mergetree テーブル用の軽量 DELETE ミューテーションを有効にします。

enable_lightweight_update​

軽量更新を使用できるようにします。

enable_memory_bound_merging_of_aggregation_results​

集約のメモリバウンドマージ戦略を有効にします。

enable_multiple_prewhere_read_steps​

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

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​

最終サブクエリへのプッシュ述語を許可します。

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; -- returns an error that ALL is ambiguous

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 に設定された場合、データはテーブルから得られたシリアライズ用のヒントに従って、カスタムシリアライズ（例：Sparse）を持つカラムに直接解析されます。

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

メモリ効率の良い集約（distributed_aggregation_memory_efficient を参照）が順序外でバケットを生成することを許可します。 集約バケットのサイズが偏っている場合、より高いIDを持つバケットを持つレプリカが、まだ処理中の低いIDのバケットを送信できることでパフォーマンスが改善される可能性があります。 欠点は、潜在的に高いメモリ使用量です。

enable_reads_from_query_cache​

オンにすると、SELECT クエリの結果が クエリキャッシュ から取得されます。

可能な値:

• 0 - 無効
• 1 - 有効

enable_s3_requests_logging​

S3 リクエストの非常に明示的なロギングを有効にします。デバッグ専用で意味があります。

enable_scalar_subquery_optimization​

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

enable_scopes_for_with_statement​

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

これは、旧アナライザーが実行できた一部の無効なクエリを実行するための新しいアナライザーの互換性設定であることに注意してください。

enable_shared_storage_snapshot_in_query​

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

これは、データ部分の内部的一貫性が重要なクエリに必要です。例：

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

この設定がない場合、外部および内部クエリは異なるデータスナップショットで操作する可能性があり、不正確な結果を引き起こすことがあります。

可能な値:

• 0 - 無効
• 1 - 有効

enable_sharing_sets_for_mutations​

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

enable_software_prefetch_in_aggregation​

集約におけるソフトウェアプリフェッチの使用を有効にします。

enable_unaligned_array_join​

異なるサイズの複数の配列との ARRAY JOIN を許可します。この設定が有効になると、配列は最も長いものにサイズ変更されます。

enable_url_encoding​

URI におけるパスのデコード/エンコードを URL エンジンテーブルで有効または無効にします。

デフォルトで無効です。

enable_vertical_final​

有効にすると、FINAL 中に重複行をマークして削除し、行をマージするのではなく、後でフィルタリングします。

enable_writes_to_query_cache​

オンにすると、SELECT クエリの結果が クエリキャッシュ に格納されます。

可能な値:

• 0 - 無効
• 1 - 有効

enable_zstd_qat_codec​

オンにすると、ZSTD_QAT コーデックを使用してカラムを圧縮することができます。

enforce_strict_identifier_format​

有効にすると、英数字およびアンダースコアを含む識別子のみを許可します。

engine_file_allow_create_multiple_files​

ファイルエンジンテーブルで、形式がサフィックス（JSON、ORC、Parquetなど）を持つ場合に、各挿入時に新しいファイルを作成するかどうかを有効または無効にします。これが有効になっている場合、各挿入時に次のパターンに従った新しいファイルが作成されます。

data.Parquet -> data.1.Parquet -> data.2.Parquet など。

可能な値:

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

engine_file_empty_if_not_exists​

ファイルなしでファイルエンジンテーブルからデータを選択することを許可します。

可能な値:

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

engine_file_skip_empty_files​

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

可能な値:

• 0 — 空のファイルがリクエストされた形式と互換性がない場合、SELECT は例外をスローします。
• 1 — 空のファイルの場合、SELECT は空の結果を返します。

engine_file_truncate_on_insert​

File エンジンテーブルで、挿入前のトランケートを有効または無効にします。

可能な値:

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

engine_url_skip_empty_files​

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

可能な値:

• 0 — 空のファイルがリクエストされた形式と互換性がない場合、SELECT は例外をスローします。
• 1 — 空のファイルの場合、SELECT は空の結果を返します。

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 will be not be updated upon insert
--SET exclude_materialize_skip_indexes_on_insert='idx_a, idx_b'; -- neither index would be updated on insert

INSERT INTO tab SELECT number, number / 50 FROM numbers(100); -- only idx_b is updated

-- since it is a session setting it can be set on a per-query level
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; -- this query can be used to explicitly materialize the index

SET exclude_materialize_skip_indexes_on_insert = DEFAULT; -- reset setting to default

execute_exists_as_scalar_subquery​

非相関 EXISTS サブクエリをスカラサブクエリとして実行します。スカラサブクエリと同様に、キャッシュが使用され、定数折りたたみが結果に適用されます。

external_storage_connect_timeout_sec​

接続タイムアウト（秒単位）。現在、MySQL のみサポートされています。

external_storage_max_read_bytes​

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

external_storage_max_read_rows​

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

external_storage_rw_timeout_sec​

読み取り/書き込みのタイムアウト（秒単位）。現在、MySQL のみサポートされています。

external_table_functions_use_nulls​

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

可能な値:

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

使用法

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

external_table_strict_query​

true に設定された場合、外部テーブルに対するクエリのローカルフィルターへの変換が禁止されます。

extract_key_value_pairs_max_pairs_per_row​

extractKeyValuePairs 関数によって生成される最大ペア数。メモリを過剰に消費することを防ぐための安全対策として使用されます。

extremes​

クエリ結果のカラム内の極端な値（最小値と最大値）をカウントするかどうかを設定します。0 または 1 を受け入れます。デフォルトは 0（無効）。 極端な値に関する詳細は、「極端な値」セクションを参照してください。

fallback_to_stale_replicas_for_distributed_queries​

更新されたデータが利用できない場合、古いレプリカへのクエリを強制します。詳細は レプリケーション を参照してください。

ClickHouse は、テーブルの古いレプリカの中で最も関連性の高いものを選択します。

レプリケーションテーブルを指す分散テーブルから SELECT を実行する際に使用されます。

デフォルトでは 1（有効）です。

filesystem_cache_boundary_alignment​

ファイルシステムキャッシュの境界アラインメント。この設定は、ディスク読み取りではない（例：リモートテーブルエンジン/テーブル関数のキャッシュ用、MergeTree テーブルのストレージ構成には適用されません）にのみ適用されます。値 0 はアラインメントなしを意味します。

filesystem_cache_enable_background_download_during_fetch​

ClickHouse Cloud でのみ有効です。ファイルシステムキャッシュ内でスペース確保のためのキャッシュロックの待機時間。

filesystem_cache_enable_background_download_for_metadata_files_in_packed_storage​

ClickHouse Cloud でのみ有効です。ファイルシステムキャッシュ内でスペース確保のためのキャッシュロックの待機時間。

filesystem_cache_max_download_size​

単一のクエリによってダウンロード可能な最大リモートファイルシステムキャッシュサイズ。

filesystem_cache_name​

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

filesystem_cache_prefer_bigger_buffer_size​

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

filesystem_cache_reserve_space_wait_lock_timeout_milliseconds​

ファイルシステムキャッシュ内でスペース確保のためのキャッシュロックの待機時間。

filesystem_cache_segments_batch_size​

読み取りバッファがキャッシュからリクエストできるファイルセグメントのバッチサイズの制限。低すぎる値はキャッシュへのリクエストを過剰に引き起こし、高すぎる値はキャッシュからの追放を遅くする可能性があります。

filesystem_cache_skip_download_if_exceeds_per_query_cache_write_limit​

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

filesystem_prefetch_max_memory_usage​

プリフェッチのための最大メモリ使用量。

filesystem_prefetch_step_bytes​

バイト単位のプリフェッチステップ。ゼロは auto を意味します -おおよその最適なプリフェッチステップが自動的に推論されますが、100％最適であるとは限りません。実際の値は、設定 filesystem_prefetch_min_bytes_for_single_read_task によって異なる可能性があります。

filesystem_prefetch_step_marks​

マーク単位のプリフェッチステップ。ゼロは auto を意味します -おおよその最適なプリフェッチステップが自動的に推論されますが、100％最適であるとは限りません。実際の値は、設定 filesystem_prefetch_min_bytes_for_single_read_task によって異なる可能性があります。

filesystem_prefetches_limit​

プリフェッチの最大数。ゼロは制限なしを意味します。プリフェッチの数を制限したい場合は、設定 filesystem_prefetches_max_memory_usage が推奨されます。

final​

すべてのクエリ内のテーブルに自動的に FINAL修飾子を適用し、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 │
└─────┴────────┘

flatten_nested​

ネストされた カラムのデータ形式を設定します。

可能な値:

• 1 — ネストされたカラムが別の配列に平坦化されます。
• 0 — ネストされたカラムはタプルの単一配列のままです。

使用法

設定が 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=''; -- query will produce CANNOT_PARSE_TEXT error.
SELECT * FROM data_01515 SETTINGS force_data_skipping_indices='d1_idx'; -- query will produce INDEX_NOT_USED error.
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 (example of full featured parser).
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='`d1_idx`, d1_null_idx'; -- query will produce INDEX_NOT_USED error, since d1_null_idx is 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 系列のテーブルで機能します。

force_index_by_date=1 の場合、ClickHouse はクエリがデータ範囲を制限するために使用できる日付キー条件を持っているかどうかを確認します。適切な条件がない場合、例外をスローします。しかし条件がデータを読み込む量を減らすかどうかは確認しません。たとえば、条件 Date != '2000-01-01' は、テーブル内のすべてのデータに一致しても受け入れられます（つまり、クエリの実行にはフルスキャンが必要です）。MergeTree テーブルのデータ範囲に関する詳細は、MergeTree を参照してください。

force_optimize_projection​

SELECT クエリで プロジェクション の必須使用を有効または無効にします。プロジェクション最適化が有効な場合（optimize_use_projections 設定を参照）。

可能な値:

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

force_optimize_projection_name​

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

可能な値:

• 文字列：クエリで使用されるプロジェクションの名前。

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 を有効にします。
• 2 — 2 番目のレベルまで force_optimize_skip_unused_shards を有効にします。

force_primary_key​

主キーによるインデックスが不可能な場合、クエリの実行を無効にします。

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

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 のスケール量の桁数だけを印刷します。

formatdatetime_f_prints_single_zero​

関数 'formatDateTime' のフォーマッター '%f' は、フォーマットされた値に小数秒がない場合、6つのゼロの代わりに単一のゼロを印刷します。

formatdatetime_format_without_leading_zeros​

関数 'formatDateTime' のフォーマッター '%c'、'%l'、'%k' は、月や時間を先頭のゼロなしで印刷します。

formatdatetime_parsedatetime_m_is_month_name​

関数 'formatDateTime' および 'parseDateTime' のフォーマッター '%M' は、分の代わりに月名を印刷/解析します。

fsync_metadata​

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

サーバーに継続的に作成されては消されるミニマムのテーブルが何百万もある場合は無効にする意味があります。

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 関数で複雑な型（構造体、配列、マップなど）を返すことを許可するかどうかを制御します。

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 によって生成されるデータ量の安全閾値を設定します。データのブロックあたりによって生成される値の最大数を定義します（ブロック内の各行の配列のサイズの合計）。

可能な値:

• 正の整数。

関連項目

• max_block_size
• min_insert_block_size_rows

function_sleep_max_microseconds_per_block​

関数 sleep がブロックごとに許可される最大マイクロ秒数。ユーザーがこれを大きな値で呼び出した場合、例外がスローされます。それは安全の閾値です。

function_visible_width_behavior​

visibleWidth 機能の動作のバージョン。0 - コードポイントの数のみをカウント; 1 - ゼロ幅および組み合わせ文字を正しくカウントし、全幅文字を二つとしてカウントし、タブ幅を見積もり、削除文字をカウントします。

geo_distance_returns_float64_on_float64_arguments​

geoDistance、greatCircleDistance、greatCircleAngle 関数のすべての四つの引数が 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_max_buckets​

グレースハッシュ結合のバケット数の制限。

group_by_overflow_mode​

集約のためのユニークキーの数が制限を超えた場合に何が起こるかを設定します：

• throw: 例外をスローします
• break: クエリの実行を停止し、部分的な結果を返します
• any: セットに追加される新しいキーを追加せず、セットに含まれるキーの集約を続けます。

'any' 値を使用することで、GROUP BY の近似を実行できます。この近似の質はデータの統計的性質に依存します。

group_by_two_level_threshold​

キー数がいくつであれば、二重集約を開始するか。0 - 阈値は設定されていません。

group_by_two_level_threshold_bytes​

バイト数で集計状態のサイズがいくつであれば、二重集約を開始するか。0 - 阈値は設定されていません。いずれかの閾値がトリガーされると、二重集約が使用されます。

group_by_use_nulls​

GROUP BY 句 が集約キーのタイプを扱う方法を変更します。 ROLLUP、CUBE、または GROUPING SETS 修飾子が使用される場合、一部の集約キーが結果行を生成するために使用されない場合があります。 これらのキーのカラムは、この設定に応じてデフォルト値または NULL で対応する行に埋められます。

可能な値：

• 0 — 集約キータイプのデフォルト値が欠けている値を生成するために使用されます。
• 1 — ClickHouse は SQL 標準が言うとおりに 'GROUP BY' を実行します。集約キーのタイプは Nullable に変換されます。対応する集約キーのカラムには、それを使用しなかった行に対して NULL が埋められます。

参照：

• GROUP BY 句

h3togeo_lon_lat_result_order​

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

handshake_timeout_ms​

レプリカとのハンドシェーク中に Hello パケットを受信するためのミリ秒単位のタイムアウト。

hdfs_create_new_file_on_insert​

HDFSエンジンテーブルに挿入するたびに新しいファイルを作成するかどうかを有効または無効にします。 有効にすると、各挿入時に以下のようなパターンの名前で新しいHDFSファイルが作成されます。

初期: data.Parquet.gz -> data.1.Parquet.gz -> data.2.Parquet.gz など。

可能な値:

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

グロブ展開ルールに従って一致するファイルがゼロの場合にエラーをスローします。

可能な値:

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

hdfs_truncate_on_insert​

HDFSエンジンテーブルで挿入の前に切り詰めを有効または無効にします。無効にすると、HDFSにファイルがすでに存在する場合、挿入をしようとすると例外がスローされます。

可能な値:

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

hedged_connection_timeout_ms​

ヘッジリクエスト用にレプリカとの接続を確立するための接続タイムアウト。

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ヘッダX-ClickHouse-Progressを送信しない。

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パラメータから解析できず、ユーザープロファイルで設定する必要があります。クエリ実行開始前にコンテンツが解析され、外部テーブルがメモリ内で作成されることに注意してください。これは、この段階に影響を与える唯一の制限です（最大メモリ使用量と最大実行時間の制限はHTTPフォームデータの読み取り時には影響しません）。

http_max_request_param_data_size​

事前定義されたHTTPリクエストにおけるクエリパラメータとして使用されるリクエストデータのサイズ制限。

http_max_tries​

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

http_max_uri_size​

HTTPリクエストの最大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_response_headers​

成功したクエリ結果の応答でサーバーが返すHTTPヘッダを追加または上書きできるようにします。これはHTTPインターフェースにのみ影響します。

デフォルトでヘッダーがすでに設定されている場合、提供された値がそれを上書きします。デフォルトでヘッダーが設定されていない場合、それはヘッダーのリストに追加されます。この設定によって上書きされていないサーバーによってデフォルトで設定されているヘッダーは残ります。

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

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

ユーザーが設定を変更するUIアプリケーションを実装し、同時に返されたヘッダーに基づいて決定を下す場合、この設定を読み取り専用に制限することをお勧めします。

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

http_retry_initial_backoff_ms​

再試行時のバックオフの最小ミリ秒数。

http_retry_max_backoff_ms​

再試行時のバックオフの最大ミリ秒数。

http_send_timeout​

HTTP送信タイムアウト（秒単位）。

可能な値:

• 任意の正の整数。
• 0 - 無効（無限のタイムアウト）。

http_skip_not_found_url_for_globs​

HTTP_NOT_FOUNDエラーを伴うグロブの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_delete_data_on_drop​

ドロップ時にすべてのアイスバーグファイルを削除するかどうか。

iceberg_insert_max_bytes_in_data_file​

挿入操作におけるアイスバーグパーケットデータファイルの最大行数。

iceberg_insert_max_rows_in_data_file​

挿入操作におけるアイスバーグパーケットデータファイルの最大行数。

iceberg_metadata_compression_method​

.metadata.jsonファイルを圧縮する方法。

iceberg_metadata_log_level​

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

可能な値:

• none - メタデータログなし。
• metadata - ルートmetadata.jsonファイル。
• manifest_list_metadata - 上記のすべて + スナップショットに対応するavroマニフェストリストのメタデータ。
• manifest_list_entry - 上記のすべて + avroマニフェストリストのエントリ。
• manifest_file_metadata - 上記のすべて + 遷移したavroマニフェストファイルのメタデータ。
• manifest_file_entry - 上記のすべて + 遷移したavroマニフェストファイルのエントリ。

iceberg_snapshot_id​

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

iceberg_timestamp_ms​

特定のタイムスタンプで現在のスナップショットを使用してIcebergテーブルをクエリします。

idle_connection_timeout​

指定された秒数後にアイドルTCP接続を閉じるためのタイムアウト。

可能な値:

• 正の整数（0 - 即時閉鎖、0秒後）。

ignore_cold_parts_seconds​

ClickHouse Cloudでのみ効果があります。新しいデータパーツをSELECTクエリから除外し、プレウォームされるまで（cache_populated_by_fetchを参照）または指定された秒古くなるまで。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=''; -- query will produce CANNOT_PARSE_TEXT error.
SELECT * FROM data SETTINGS ignore_data_skipping_indices='x_idx'; -- Ok.
SELECT * FROM data SETTINGS ignore_data_skipping_indices='na_idx'; -- Ok.

SELECT * FROM data WHERE x = 1 AND y = 1 SETTINGS ignore_data_skipping_indices='xy_idx',force_data_skipping_indices='xy_idx' ; -- query will produce INDEX_NOT_USED error, since xy_idx is explicitly ignored.
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ファミリーのテーブルで機能します。

ignore_drop_queries_probability​

有効にすると、サーバーは指定された確率ですべてのDROPテーブルクエリを無視します（メモリおよびJOINエンジンの場合、DROPをTRUNCATEに置き換えます）。テスト目的で使用されます。

ignore_materialized_views_with_dropped_target_table​

ビューへのプッシュ時にターゲットテーブルが削除されたマテリアライズドビューを無視します。

ignore_on_cluster_for_replicated_access_entities_queries​

レプリケートアクセス実体管理クエリのON CLUSTER句を無視します。

ignore_on_cluster_for_replicated_named_collections_queries​

レプリケートされたネームドコレクション管理クエリの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​

有効であり、すでにトランザクション内でない場合、クエリを完全なトランザクション（開始 + コミットまたはロールバック）内にラップします。

input_format_parallel_parsing​

データフォーマットの順序を保持する並列解析を有効または無効にします。TSV、TSKV、CSV、およびJSONEachRow形式のみに対応しています。

可能な値:

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

insert_allow_materialized_columns​

設定が有効になっている場合、INSERTでマテリアライズドカラムを許可します。

insert_deduplicate​

INSERT（Replicated*テーブル用）のブロック重複排除を有効または無効にします。

可能な値:

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

デフォルトでは、INSERT文によってレプリケートテーブルに挿入されたブロックは重複排除されます（データレプリケーションを参照）。

レプリケートテーブルでは、デフォルトで各パーティションの最近の100のブロックのみが重複排除されます（replicated_deduplication_window、replicated_deduplication_window_secondsを参照）。非レプリケートテーブルについては、non_replicated_deduplication_windowを参照してください。

insert_deduplication_token​

設定により、ユーザーはMergeTree/ReplicatedMergeTreeにおける独自の重複排除セマンティクスを提供できます。たとえば、各INSERT文に設定のユニークな値を提供することで、同じ挿入データが重複排除されるのを回避できます。

可能な値:

• 任意の文字列

insert_deduplication_tokenは、空でない場合にのみ重複排除に使用されます。

レプリケートテーブルではデフォルトで、各パーティションの最近の100件の挿入のみが重複排除されます（replicated_deduplication_window、replicated_deduplication_window_secondsを参照）。非レプリケートテーブルについては、non_replicated_deduplication_windowを参照してください。

例：

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

-- the next insert won't be deduplicated because insert_deduplication_token is different
INSERT INTO test_table SETTINGS insert_deduplication_token = 'test1' VALUES (1);

-- the next insert will be deduplicated because insert_deduplication_token
-- is the same as one of the previous
INSERT INTO test_table SETTINGS insert_deduplication_token = 'test' VALUES (2);

SELECT * FROM test_table

┌─A─┐
│ 1 │
└───┘
┌─A─┐
│ 1 │
└───┘

insert_keeper_fault_injection_probability​

挿入中のキーパーリクエストの故障確率の概算。有効な値は[0.0f, 1.0f]の範囲内。

insert_keeper_fault_injection_seed​

0 - ランダムシード、その他は設定値。

insert_keeper_max_retries​

設定は、レプリケートされたMergeTreeへの挿入中のClickHouse Keeper（またはZooKeeper）リクエストの最大試行回数を設定します。ネットワークエラー、キーパーセッションタイムアウト、またはリクエストタイムアウトにより失敗したキーパーミリクエストのみが再試行の対象となります。

可能な値:

• 正の整数。
• 0 — 再試行は無効。

クラウドのデフォルト値：20。

キーパーリクエストの再試行は、いくつかのタイムアウト後に行われます。タイムアウトは、次の設定で制御されます：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となります。

故障耐性だけでなく、再試行はより良いユーザーエクスペリエンスを提供することを目指しています - これにより、挿入実行中にエラーを返すのを避けることができます。これは、キーパーがアップグレードのために再起動された場合などです。

insert_keeper_retry_initial_backoff_ms​

挿入クエリ実行中に失敗したキーパーリクエストを再試行するための初期タイムアウト（ミリ秒単位）。

可能な値:

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

insert_keeper_retry_max_backoff_ms​

挿入クエリ実行中に失敗したキーパーリクエストを再試行するための最大タイムアウト（ミリ秒単位）。

可能な値:

• 正の整数。
• 0 — 最大タイムアウトは制限なし。

insert_null_as_default​

nullableでないデータ型のカラムにNULLの代わりにデフォルト値を挿入することを有効または無効にします。カラムタイプがnullableでない場合、この設定が無効な場合、NULLを挿入すると例外が発生します。カラムタイプがnullableであれば、NULL値はこの設定に関係なくそのまま挿入されます。

この設定はINSERT ... SELECTクエリに適用されます。SELECTサブクエリは、UNION ALL句で連結される場合があります。

可能な値:

• 0 — nullableでないカラムにNULLを挿入すると例外が発生します。
• 1 — NULLの代わりにデフォルトのカラム値が挿入されます。

insert_quorum​

クオラム書き込みを有効にします。

• 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_quorum_timeout
• insert_quorum_parallel
• select_sequential_consistency

insert_quorum_parallel​

クオラム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を使用してフラッシュできます。サンプルは、jemalloc_collect_global_profile_samples_in_trace_log設定またはクエリ設定jemalloc_collect_profile_samples_in_trace_logでシステム.trace_logに保存されることもあります。 Allocation Profilingを参照してください。

join_algorithm​

使用されるJOINアルゴリズムを指定します。

いくつかのアルゴリズムを指定でき、特定のクエリに対して使用可能なものが選択されます。その選択は種類/厳密さおよびテーブルエンジンに基づきます。

可能な値：

• grace_hash

  Grace hash joinが使用されます。Grace hashは、メモリ使用量を制限しつつ、パフォーマンスの高い複雑な結合を提供するアルゴリズムオプションを提供します。

  grace joinの最初のフェーズは、右側のテーブルを読み取り、キー列のハッシュ値に応じてNバケットに分割します（最初に、Nはgrace_hash_join_initial_bucketsに設定されています）。これは、各バケットが独立して処理できるように行われます。最初のバケットの行はインメモリハッシュテーブルに追加され、他はディスクに保存されます。ハッシュテーブルがメモリ制限を超えると（例：max_bytes_in_joinで設定された）、バケットの数が増加し、各行の割り当てバケットが再割り当てされます。現在のバケットに属さない行はフラッシュされ、再割り当てされます。

  INNER/LEFT/RIGHT/FULL ALL/ANY JOINをサポートします。

• hash

  Hash joinアルゴリズムが使用されます。最も一般的な実装で、すべての種類と厳密さの組み合わせとJOIN ONセクションでORで結合された複数の結合キーをサポートします。

  hashアルゴリズムを使用する場合、JOINの右側はRAMにアップロードされます。

• parallel_hash

  hash結合の変種で、データをバケットに分割し、同時に複数のハッシュテーブルを構築することでこのプロセスを高速化します。

  parallel_hashアルゴリズムを使用する場合、JOINの右側はRAMにアップロードされます。

• partial_merge

  ソートマージアルゴリズムの変種で、右側のテーブルのみが完全にソートされています。

  RIGHT JOINとFULL JOINは、ALLの厳密さでのみサポートされます（SEMI、ANTI、ANY、ASOFはサポートされません）。

  partial_mergeアルゴリズムを使用する際、ClickHouseはデータをソートし、それをディスクにダンプします。ClickHouseのpartial_mergeアルゴリズムは、古典的な実現と少し異なります。最初に、ClickHouseは結合キーに基づいてブロックごとに右側のテーブルをソートし、ソートブロックの最小・最大インデックスを作成します。次に、左側のテーブルの一部をjoin keyに基づいてソートし、右側のテーブルに参加させます。最小・最大インデックスも、不要な右側のテーブルブロックをスキップするために使用されます。

• direct

  このアルゴリズムは、右側のテーブルがキーバリューリクエストをサポートするストレージである場合に適用できます。

  directアルゴリズムは、左側のテーブルからの行をキーとして使用して右側のテーブルをルックアップします。これは、DictionaryやEmbeddedRocksDBなどの特別なストレージにのみ対応し、LEFTおよびINNER JOINのみをサポートします。

• auto

  autoに設定すると、最初にhash結合が試みられ、メモリ制限が違反された場合には別のアルゴリズムに自動的に切り替えられます。

• full_sorting_merge

  ソートマージアルゴリズムを使用して、結合する前に完全にソートされたテーブルを結合します。

• prefer_partial_merge

  ClickHouseは、可能であれば常にpartial_merge結合を使用しようとします。それ以外の場合は、hashを使用します。廃止予定、partial_merge,hashと同様です。

• default (廃止予定)

  レガシー値で、もはや使用しないでください。direct,hashと同様です。すなわち、最初に直接結合を、次にハッシュ結合を使用しようとします（この順序で）。

join_any_take_last_row​

ANYの厳密さを使用した結合操作の動作を変更します。

可能な値：

• 0 — 右側のテーブルに複数の一致する行がある場合、最初に見つかった行のみが結合されます。
• 1 — 右側のテーブルに複数の一致する行がある場合、最後に見つかった行のみが結合されます。

次も参照してください：

• JOIN句
• Joinテーブルエンジン
• join_default_strictness

join_default_strictness​

JOIN句のデフォルト厳密さを設定します。

可能な値：

• ALL — 右側のテーブルに複数の一致する行がある場合、ClickHouseは一致する行からデカルト積を作成します。これは標準SQLからの通常のJOINの動作です。
• ANY — 右側のテーブルに複数の一致する行がある場合、最初に見つかった行のみが結合されます。右側のテーブルに一致する行が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​

ClickHouseが以下のいずれかの結合制限に達した際に行うアクションを定義します：

• max_bytes_in_join
• max_rows_in_join

可能な値：

• THROW — ClickHouseは例外をスローし、操作を中断します。
• BREAK — ClickHouseは操作を中断し、例外をスローしません。

デフォルト値：THROW。

次も参照してください

• JOIN句
• Joinテーブルエンジン

join_runtime_bloom_filter_bytes​

JOINランタイムフィルタとして使用されるブルームフィルタのサイズ（バイト単位）。(設定を参照してくださいenable_join_runtime_filters)。

join_runtime_bloom_filter_hash_functions​

JOINランタイムフィルタとして使用されるブルームフィルタのハッシュ関数の数（設定を参照してくださいenable_join_runtime_filters）。

join_to_sort_maximum_table_rows​

右側のテーブルの行数の最大値。左結合または内部結合において、右側のテーブルをキーで再配置するかどうかを決定します。

join_to_sort_minimum_perkey_rows​

右側のテーブルでのキーごとの平均行数の下限。左結合または内部結合において、右側のテーブルをキーで再配置するかどうかを決定します。この設定は、希薄テーブルのキーには最適化が適用されないことを保証します。

join_use_nulls​

JOIN の動作タイプを設定します。テーブルをマージする際に、空のセルが現れる場合があります。この設定に基づいて、ClickHouseはそれらを異なる方法で満たします。

可能な値:

• 0 — 空のセルは、対応するフィールドタイプのデフォルト値で埋められます。
• 1 — JOIN は標準SQLと同様に動作します。対応するフィールドのタイプはNullableに変換され、空のセルはNULLで埋められます。

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での操作中に追加のチェックを強制します。例えば、既に存在するキーへの挿入で例外をスローします。

keeper_max_retries​

一般的なキーパー操作の最大再試行回数

keeper_retry_initial_backoff_ms​

一般的なキーパー操作のための初期バックオフタイムアウト

keeper_retry_max_backoff_ms​

一般的なキーパー操作のための最大バックオフタイムアウト

least_greatest_legacy_null_behavior​

有効な場合、関数 'least' と 'greatest' は、その引数の1つがNULLである場合にNULLを返します。

legacy_column_name_of_tuple_literal​

大きなタプルリテラルの各要素の名前をハッシュの代わりにカラム名としてリストします。この設定は互換性の理由からのみ存在します。21.7未満のバージョンからより高いバージョンにクラスタをローリングアップデートする際に'true'に設定することが意味があります。

lightweight_delete_mode​

軽量削除の一環として実行される内部更新クエリのモード。

可能な値:

• alter_update - ヘビーウェイトの変異を作成するALTER UPDATEクエリを実行します。
• lightweight_update - 可能であれば軽量更新を実行し、そうでなければALTER UPDATEを実行します。
• lightweight_update_force - 可能であれば軽量更新を実行し、そうでなければ例外をスローします。

lightweight_deletes_sync​

mutations_syncと同様ですが、軽量削除の実行のみを制御します。

可能な値:

関連情報

• ALTERクエリの同期性
• 変異

limit​

クエリ結果から取得する最大行数を設定します。LIMIT句によって設定されている値を調整し、クエリに指定された制限がこの設定によって設定された制限を超えないようにします。

可能な値:

• 0 — 行数に制限なし。
• 正の整数。

live_view_heartbeat_interval​

ライブクエリが生きていることを示す心拍間隔（秒）。

load_balancing​

分散クエリ処理で使用されるレプリカ選択アルゴリズムを指定します。

ClickHouseは以下のレプリカ選択アルゴリズムをサポートしています：

• ランダム（デフォルト）
• 最寄のホスト名
• ホスト名レーベンシュタイン距離
• 順番に
• 最初またはランダム
• ラウンドロビン

関連情報:

• distributed_replica_max_ignored_errors

ランダム（デフォルト）​

load_balancing = random

各レプリカのエラー数をカウントします。クエリは、最も少ないエラーを持つレプリカに送信され、それが複数ある場合はそのうちの一つに送信されます。 欠点: サーバーの近接性は考慮されません; レプリカが異なるデータを持つ場合、異なるデータも受け取ります。

最寄のホスト名​

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

同じ数のエラーを持つレプリカにアクセスする際、設定されている順序でアクセスされます。 この方法は、どのレプリカが好ましいかが正確に分かっているときに適切です。

最初またはランダム​

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マークを非同期で読み込みます。

local_filesystem_read_method​

ローカルファイルシステムからデータを読み取る方法の一つ：read, pread, mmap, io_uring, pread_threadpool。

'io_uring'メソッドは実験的であり、Log, TinyLog, StripeLog, File, SetおよびJoin、ならびに同時読み取りと書き込みが存在する場合の他のテーブルでは機能しません。 インターネット上で'io_uring'に関するさまざまな記事を読む際は、それに目を奪われないようにしてください。それは ClickHouseにおける小さなIOリクエストの量が多い場合を除いては、ファイルを読み取るための優れた方法ではありません。したがって、'io_uring'を有効にする理由はありません。

local_filesystem_read_prefetch​

ローカルファイルシステムからデータを読み取る際にプレフェッチを使用すべきです。

lock_acquire_timeout​

ロック要求が失敗するまでの待機時間（秒）を定義します。

ロックタイムアウトは、テーブルでの読み取り/書き込み操作中にデッドロックから保護するために使用されます。タイムアウトが経過してロック要求が失敗すると、ClickHouse サーバーは「ロックの試行がタイムアウトしました！可能性のあるデッドロックを回避しました。クライアントは再試行する必要があります。」という例外をスローし、エラーコードDEADLOCK_AVOIDEDが付与されます。

可能な値:

• 正の整数（秒）。
• 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​

有効（非ゼロ）の場合、この設定の値よりも速いクエリはログに記録されません（これを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システムテーブルに書き込むことを許可します。これにより、大量のクエリの負荷を軽減します。

可能な値:

• 0 — クエリはシステムテーブルに記録されません。
• 0..1の範囲内の正の浮動小数点数。例えば、設定値が0.5であれば、約半分のクエリがシステムテーブルに記録されます。
• 1 — すべてのクエリがシステムテーブルにログ記録されます。

log_query_settings​

クエリ設定をquery_logおよびOpenTelemetryスパンログに記録します。

log_query_threads​

クエリスレッドのログ記録を設定します。

クエリスレッドはsystem.query_thread_logテーブルにログ記録されます。この設定は、log_queriesがtrueの場合にのみ有効です。この設定を持ってClickHouseによって実行されるクエリのスレッドは、query_thread_logサーバー設定パラメータのルールに従って記録されます。

可能な値:

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

例

log_query_threads=1

log_query_views​

クエリのビュー記録を設定します。

この設定が有効な状態でClickHouseによって実行されるクエリが関連するビュー（マテリアライズドまたはライブビュー）を持つ場合、それらはquery_views_logサーバー設定パラメータに記録されます。

例:

log_query_views=1

low_cardinality_allow_in_native_format​

LowCardinalityデータ型をNativeフォーマットで使用することを許可または制限します。

LowCardinalityの使用が制限される場合、ClickHouseサーバーはSELECTクエリのLowCardinalityカラムを通常のカラムに変換し、INSERTクエリの通常のカラムをLowCardinalityカラムに変換します。

この設定は主にLowCardinalityデータ型をサポートしていないサードパーティのクライアント向けに必要です。

可能な値:

• 1 — LowCardinalityの使用に制限なし。
• 0 — LowCardinalityの使用に制限あり。

low_cardinality_max_dictionary_size​

LowCardinalityデータ型のための共有グローバル辞書の最大サイズを設定します。この設定により、辞書が無制限に成長することによるRAMの問題を防ぎます。最大辞書サイズ制限のためにエンコードできないすべてのデータは、ClickHouseが通常の方法で書き込まれます。

可能な値:

• 任意の正の整数。

low_cardinality_use_single_dictionary_for_part​

データ部分に対する単一辞書の使用をオンまたはオフにします。

デフォルトでは、ClickHouseサーバーは辞書のサイズを監視し、辞書がオーバーフローすると次の辞書の書き込みを開始します。複数の辞書の作成を禁止するには、low_cardinality_use_single_dictionary_for_part = 1を設定します。

可能な値:

• 1 — データ部分に対する複数の辞書の作成が禁止されます。
• 0 — データ部分に対する複数の辞書の作成が禁止されない。

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​

マテリアライズドビューのエラーを無視し、MVに関係なく元のブロックをテーブルに配信することを許可します。

materialized_views_squash_parallel_inserts​

並列INSERTからの単一INSERTクエリのマテリアライズドビュー宛先テーブルへの挿入を圧縮し、生成されたパーツの数を減らします。 falseに設定し、parallel_view_processingが有効な場合、INSERTクエリはmax_insert_threadごとに宛先テーブルに部分を生成します。

max_analyze_depth​

インタープリターが実行する分析の最大数。

max_ast_depth​

クエリの構文木の最大入れ子の深さ。これを超えると例外がスローされます。

max_ast_elements​

クエリの構文木の最大要素数。これを超えると例外がスローされます。

max_autoincrement_series​

generateSeriesID関数によって作成されるシリーズの数の制限。

各シリーズはKeeper内のノードを表すため、数百万を超えないことが推奨されます。

max_backup_bandwidth​

特定のバックアップのサーバーでの最大読み取り速度（バイト毎秒）。ゼロは無制限を意味します。

max_block_size​

ClickHouseでは、データはカラムパーツのセットであるブロックによって処理されます。個々のブロックに対する内部処理サイクルは効率的ですが、各ブロックを処理する際には顕著なコストがあります。

max_block_size設定は、テーブルからデータを読み込むときの単一ブロックに含めることが推奨される最大行数を示します。max_block_sizeサイズのブロックは常にテーブルから読み込まれるわけではありません。もしClickHouseが取得する必要があるデータが少ないと判断した場合、より小さなブロックが処理されます。

ブロックサイズはあまりにも小さくなってはいけません。なぜなら、各ブロックを処理する際に顕著なコストがかかるからです。また、クエリがLIMIT句を持つ場合、最初のブロックを処理した後に効率よく実行できるよう、大きすぎてもいけません。max_block_sizeを設定する際は、大量のカラムを複数スレッドで抽出する際にメモリを消費しすぎず、ある程度のキャッシュの局所性を確保することを目指します。

max_bytes_before_external_group_by​

クラウドデフォルト値：レプリカごとのメモリ量の半分。

外部メモリでのGROUP BY句の実行を有効または無効にします。 （外部メモリでのGROUP BYを参照）

可能な値:

• 単一のGROUP BY操作で使用できるRAMの最大ボリューム（バイト）。
• 0 — 外部メモリでのGROUP BYが無効。

max_bytes_before_external_sort​

クラウドデフォルト値：レプリカごとのメモリ量の半分。

外部メモリでのORDER BY句の実行を有効または無効にします。詳細については、ORDER BY実装の詳細を参照してください。 ORDER BY操作中のメモリ使用量がこの閾値（バイト）を超えた場合、'external sorting'モード（データをディスクにスワップします）が有効になります。

可能な値:

• 単一のORDER BY操作で使用できるRAMの最大ボリューム（バイト）。 推奨値は、使用可能なシステムメモリの半分です。
• 0 — 外部メモリでのORDER BYが無効。

max_bytes_before_remerge_sort​

ORDER BY句がLIMITを持つ場合、メモリ使用量が指定された閾値を超えたとき、最終マージの前にブロックをマージする追加ステップを実行して、上位LIMIT行のみを保持します。

max_bytes_in_distinct​

DISTINCTを使用する際にハッシュテーブルがメモリで使用する状態の最大バイト数（非圧縮バイト）。

max_bytes_in_join​

テーブルを結合する際に使用されるハッシュテーブルの最大サイズ（バイト数）。

この設定は、SELECT ... JOIN操作およびJoinテーブルエンジンに適用されます。

クエリに結合が含まれている場合、ClickHouseは各中間結果に対してこの設定を確認します。

制限に達した場合、ClickHouseは異なるアクションを取ることができます。アクションを選択するには、join_overflow_modeの設定を使用します。

可能な値:

• 正の整数。
• 0 — メモリ制御が無効。

max_bytes_in_set​

サブクエリから作成されたIN句内のセットによって使用される最大バイト数（非圧縮データ）。

max_bytes_ratio_before_external_group_by​

GROUP BYに許可されている利用可能メモリの比率。一度達成されると、集計に外部メモリが使用されます。

例えば、0.6に設定されている場合、GROUP BYは実行の開始時に利用可能なメモリの60%をサーバー/ユーザー/マージに使用することを許可します。それ以降は、外部集計を使用し始めます。

max_bytes_ratio_before_external_sort​

ORDER BYに許可されている利用可能メモリの比率。一度達成されると、外部ソートが使用されます。

例えば、0.6に設定されている場合、ORDER BYは実行の開始時に利用可能なメモリの60%（サーバー/ユーザー/マージ）を使用することを許可します。それ以降は、外部ソートを使用し始めます。

max_bytes_before_external_sortは依然として考慮され、ソートブロックがmax_bytes_before_external_sortを超えると、ディスクにスワップされます。

max_bytes_to_read​

クエリを実行するときに、テーブルから読み取ることができる最大バイト数（非圧縮データ）。 制限は、処理される各データチャンクに対して確認され、最も深いテーブル式に適用され、リモートサーバーから読み取る際には、リモートサーバーのみで確認されます。

max_bytes_to_read_leaf​

分散クエリ実行中に、リーフノードのローカルテーブルから読み取ることができる最大バイト数（非圧縮データ）。分散クエリは各シャード（リーフ）に複数のサブクエリを発行できるが、この制限はリーフノードでの読み取り段階でのみ確認され、ルートノードでの結果をマージする段階では無視されます。

例えば、クラスターが2つのシャードを持ち、それぞれのシャードが100バイトのデータを持つテーブルを持つ場合、設定max_bytes_to_read=150の分散クエリは合計200バイトの取得を試みるため失敗します。max_bytes_to_read_leaf=150のクエリは成功します。なぜなら、リーフノードは最大で100バイトを読み取ります。

この制限は、処理される各データチャンクに対して確認されます。

max_bytes_to_sort​

ソート前の最大バイト数。指定された非圧縮バイト数を超えてORDER BY操作を処理する必要がある場合、動作はデフォルトでthrowに設定されているsort_overflow_modeによって決まります。

max_bytes_to_transfer​

GLOBAL IN/JOINセクションが実行される際に、リモートサーバーに渡すことができる最大バイト数（非圧縮データ）または一時テーブルに保存されます。

max_columns_to_read​

単一クエリでテーブルから読み取ることができる最大カラム数。 クエリが指定されたカラム数を超えて読み取りを必要とする場合、例外がスローされます。

0の値は無制限を意味します。

max_compress_block_size​

テーブルに書き込むために圧縮する前の非圧縮データの最大ブロックサイズ。デフォルトは1,048,576（1 MiB）です。一般的に、より小さなブロックサイズを指定すると、圧縮率がわずかに低下し、キャッシュの局所性により圧縮および解凍スピードがわずかに向上し、メモリ消費が減少します。

圧縮用のブロック（バイトからなるメモリのチャンク）とクエリ処理用のブロック（テーブルの行のセット）を混同しないでください。

max_concurrent_queries_for_all_users​

この設定の値が現在処理中のクエリの数以下であれば、例外をスローします。

例：全ユーザーに対してmax_concurrent_queries_for_all_usersを99に設定し、データベース管理者は100に設定して、自身によるクエリを実行してサーバーが過負荷の状態でも調査できます。

1つのクエリまたはユーザーに対して設定を変更しても、他のクエリには影響しません。

可能な値:

• 正の整数。
• 0 — 制限なし。

例

<max_concurrent_queries_for_all_users>99</max_concurrent_queries_for_all_users>

関連情報

• max_concurrent_queries

max_concurrent_queries_for_user​

ユーザーごとに同時処理可能なクエリの最大数。

可能な値:

• 正の整数。
• 0 — 制限なし。

例

<max_concurrent_queries_for_user>5</max_concurrent_queries_for_user>

max_distributed_connections​

単一のDistributedテーブルに対する単一クエリの分散処理のためのリモートサーバーに対する同時接続の最大数。クラスタ内のサーバー数以上の値は設定しないことを推奨します。

max_distributed_depth​

分散テーブルの再帰クエリの最大深さを制限します。

値を超えると、サーバーは例外をスローします。

可能な値：

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

max_download_buffer_size​

各スレッドごとの並列ダウンロード用のバッファの最大サイズ（例：URLエンジン用）。

max_download_threads​

データをダウンロードするためのスレッドの最大数（例：URLエンジン用）。

max_estimated_execution_time​

秒単位での最大クエリ実行推定時間。 timeout_before_checking_execution_speed が切れると、各データブロックごとにチェックされます。

max_execution_speed​

秒あたりの最大実行行数。 timeout_before_checking_execution_speed が切れると、各データブロックごとにチェックされます。 実行速度が高い場合、実行速度が減速されます。

max_execution_speed_bytes​

秒あたりの最大実行バイト数。 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 時間）に設定されている場合、ClickHouse は推定時間がこの 3600 秒の制限を超えると、クエリを終了します。timeout_before_checking_execution_speed を 0 に設定すると、ClickHouse は max_execution_time の基準として時計時間を使用します。

クエリの実行時間が指定された秒数を超えると、動作は 'timeout_overflow_mode' によって決定されますが、デフォルトでは throw に設定されています。

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などの他のサービスにクエリを投げたりする可能性があります。内部インフラストラクチャ（ローカルホスト上で実行されているものを含む）がない、またはサーバーを信頼する場合、リダイレクトを許可するのは安全です。ただし、URLがHTTPではなくHTTPSを使用している場合は、リモートサーバーだけでなく、あなたのISPや中間ネットワークも信頼する必要があります。

max_hyperscan_regexp_length​

hyperscan マルチマッチ関数における各正規表現の最大長を定義します。

可能な値：

• 正の整数。
• 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マルチマッチ関数におけるすべての正規表現の最大長合計を設定します。

可能な値：

• 正の整数。
• 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​

テーブルに挿入するために形成するブロックのサイズ（行数）。この設定は、サーバーがブロックを形成する場合にのみ適用されます。 例えば、HTTPインターフェースを介したINSERTの場合、サーバーはデータフォーマットを解析し、指定されたサイズのブロックを形成します。しかし、clickhouse-clientを使用する場合、クライアントはデータを自分で解析し、サーバーの 'max_insert_block_size' 設定は挿入されるブロックのサイズに影響を与えません。この設定は、INSERT SELECTを使用する場合には目的がなく、SELECT後に形成される同じブロックを使用してデータが挿入されます。

デフォルトは max_block_size より少し大きいです。これには、特定のテーブルエンジン（*MergeTree）が挿入された各ブロックのディスクへのデータ部分を形成するため、かなり大きなエンティティである理由があります。同様に、*MergeTree テーブルは挿入中にデータをソートし、十分に大きなブロックサイズがRAM内でより多くのデータをソートすることを可能にします。

max_insert_delayed_streams_for_parallel_write​

最終部分のフラッシュを遅らせるための最大ストリーム数（カラム）。デフォルト - 自動（基盤となるストレージが並列書き込みをサポートする場合、100、そうでない場合は無効）。

max_insert_threads​

INSERT SELECT クエリを実行するための最大スレッド数。

可能な値：

• 0（または1） — INSERT SELECT の並列実行なし。
• 正の整数。 1より大きい。

クラウドのデフォルト値：

• 8GiBのメモリを持つノードでは 1
• 16GiBのメモリを持つノードでは 2
• 大型ノードでは 4

並列の INSERT SELECT は、SELECT 部分が並行して実行される場合にのみ効果があります。 max_threads 設定を参照してください。 高い値は、メモリ使用量の増加をもたらします。

max_joined_block_size_bytes​

JOIN結果の最大ブロックサイズ（バイト）。 0 は無制限を意味します。

max_joined_block_size_rows​

JOIN結果の最大ブロックサイズ（行）。 0 は無制限を意味します。

max_limit_for_vector_search_queries​

この設定よりも大きなLIMITのあるSELECTクエリはベクトル類似インデックスを使用できません。ベクトル類似インデックスにおけるメモリオーバーフローを防ぐのに役立ちます。

max_live_view_insert_blocks_before_refresh​

マージ可能なブロックが削除され、クエリが再実行される後に挿入されたブロックの最大数を制限します。

max_local_read_bandwidth​

ローカル読み取りの最大速度（バイト毎秒）。

max_local_write_bandwidth​

ローカル書き込みの最大速度（バイト毎秒）。

max_memory_usage​

クラウドのデフォルト値：レプリカのRAMの量に依存します。

単一のサーバーでクエリを実行するために使用するRAMの最大量。 0の値は無制限を意味します。

この設定は使用可能なメモリの量や、マシン上の総メモリ量を考慮しません。制限は単一サーバー上の単一クエリに適用されます。

SHOW PROCESSLIST を使用して、各クエリの現在のメモリ消費量を見ることができます。 ピークメモリ消費量は各クエリごとに追跡され、ログに書き込まれます。

以下の集約関数の状態に対するメモリ使用量は完全には追跡されません：

• min
• max
• any
• anyLast
• argMin
• argMax

メモリ消費は、max_memory_usage_for_user および max_server_memory_usage のパラメータによっても制限されます。

max_memory_usage_for_user​

単一のサーバーでユーザーのクエリを実行するために使用する最大RAM量。ゼロは無制限を意味します。

デフォルトでは、量に制限はありません（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​

秒あたりのデータ交換速度を制限します。この設定はすべてのクエリに適用されます。

可能な値：

• 正の整数。
• 0 — 帯域幅制御が無効。

max_network_bandwidth_for_all_users​

秒あたりのデータ交換速度を制限します。この設定はサーバー上で実行されているすべての同時クエリに適用されます。

可能な値：

• 正の整数。
• 0 — データ速度の制御が無効。

max_network_bandwidth_for_user​

秒あたりのデータ交換速度を制限します。この設定は、単一ユーザーによって実行されるすべての同時クエリに適用されます。

可能な値：

• 正の整数。
• 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 は制限なしにパーティションを削除できることを意味します。

クラウドデフォルト値：1TB。

max_partitions_per_insert_block​

挿入された単一のブロック内の最大パーティション数を制限し、ブロックに過多のパーティションが含まれている場合は例外がスローされます。

• 正の整数。
• 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' 設定によって制御されます。 大量のパーティションを使用することは一般的な誤解です。これは、サーバーの起動時間の遅延やINSERTクエリの遅延、SELECTクエリの遅延など、深刻な性能への悪影響をもたらします。テーブルに推奨される総パーティション数は1000から10000の間です。パーティショニングはSELECTクエリを高速化することを目的としていません（ORDER BYキーが範囲クエリを速くするのに十分です）。 パーティションはデータ操作のためにあります（DROP PARTITIONなど）。"

max_partitions_to_read​

単一のクエリでアクセスできる最大パーティション数を制限します。

テーブル作成時に指定された設定値は、クエリレベルの設定で上書きできます。

可能な値：

• 正の整数
• -1 - 無制限 （デフォルト）

max_parts_to_move​

1つのクエリで移動できるパーツの数を制限します。ゼロは無制限を意味します。

max_query_size​

SQLパーサーによって解析されるクエリ文字列の最大バイト数。 INSERTクエリのVALUES節内のデータは、別のストリームパーサーによって処理され（O(1) RAM を消費）、この制限の影響を受けません。

max_read_buffer_size​

ファイルシステムから読み取るためのバッファの最大サイズ。

max_read_buffer_size_local_fs​

ローカルファイルシステムから読み取るためのバッファの最大サイズ。 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​

読み取り用のネットワークでのデータ交換の最大速度（バイト/秒）。

max_remote_write_network_bandwidth​

書き込み用のネットワークでのデータ交換の最大速度（バイト/秒）。

max_replica_delay_for_distributed_queries​

分散クエリに対する遅延レプリカを無効にします。 レプリケーションを参照してください。

設定値は秒単位です。レプリカの遅延が設定された値以上である場合、このレプリカは使用されません。

可能な値：

• 正の整数。
• 0 — レプリカの遅延はチェックされません。

ゼロ以外の遅延のあるレプリカの使用を防ぐには、このパラメータを1に設定します。

レプリケートされたテーブルを指す分散テーブルから SELECT を実行するときに使用されます。

max_result_bytes​

結果サイズをバイト単位で制限します（非圧縮）。 閾値が満たされるとデータブロックが処理された後にクエリは停止しますが、最後のブロックはカットされないため、結果サイズは閾値よりも大きくなる可能性があります。

注意点

この閾値に対するメモリ中の結果サイズが考慮されます。 結果サイズが小さい場合でも、メモリ内のより大きなデータ構造（LowCardinalityカラムの辞書やAggregateFunctionカラムのArenaを参照）を参照する可能性があるため、小さい結果サイズにもかかわらず閾値が超えることがあります。

max_result_rows​

クラウドのデフォルト値： 0。

結果の行数を制限します。サブクエリでも確認され、分散クエリのパーツをリモートサーバーで実行するときにも確認されます。 値が 0 の場合、制限は適用されません。

閾値が満たされると、データブロックが処理された後にクエリは停止しますが、最後のブロックはカットされないため、結果サイズは閾値よりも大きくなる可能性があります。

max_rows_in_distinct​

DISTINCTを使用する際の最大異なる行数。

max_rows_in_join​

テーブルを結合する際に使用されるハッシュテーブルにおける行数の制限です。

この設定は SELECT ... JOIN 操作および Join テーブルエンジンに適用されます。

クエリに複数の結合が含まれている場合、ClickHouse はすべての中間結果に対してこの設定をチェックします。

制限に達した場合、ClickHouse は異なるアクションを行うことができます。 join_overflow_mode 設定を使用してアクションを選択します。

可能な値：

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

max_rows_in_set​

サブクエリから作成されたIN句内のデータセットの最大行数。

max_rows_in_set_to_optimize_join​

結合テーブルを他の行セットでフィルタリングするための最大サイズです。

可能な値：

• 0 — 無効。
• 任意の正の整数。

max_rows_to_group_by​

集約から受け取るユニークキーの最大数。この設定により、集約時のメモリ消費を制限できます。

GROUP BYによる集約が指定された行数（ユニークなGROUP BYキー）を超える場合、その動作は、デフォルトで throw に設定されている group_by_overflow_mode によって決定されます。近似GROUP BYモードに切り替えることもできます。

max_rows_to_read​

クエリを実行しているときに、テーブルから読み取ることができる最大行数。 この制限は、各処理されたデータチャンクに対してチェックされ、最深のテーブル式にのみ適用され、リモートサーバーから読み取る際にはリモートサーバーでのみチェックされます。

max_rows_to_read_leaf​

分散クエリを実行する際に、葉ノードのローカルテーブルから読み取ることができる最大行数。このため、分散クエリは各シャード（葉）に複数のサブクエリを発行できますが、この制限は読み取り段階でのみ葉ノードでチェックされ、結果のマージ段階ではルートノードで無視されます。

例えば、クラスターが2つのシャードから構成され、各シャードに100行のテーブルが含まれている場合。設定が max_rows_to_read=150 の分散クエリは失敗します。なぜなら、合計で200行があるからです。一方、max_rows_to_read_leaf=150 のクエリは成功します。なぜなら、葉ノードでは最大100行が読み取られるからです。

この制限は各処理されたデータチャンクに対してチェックされます。

max_rows_to_sort​

ソート前の最大行数。この設定により、ソート時のメモリ消費を制限できます。 指定されたレコードよりも多くのレコードをORDER BY操作で処理する必要がある場合、その動作は sort_overflow_mode によって決定されます。このデフォルトは throw に設定されています。

max_rows_to_transfer​

GLOBAL IN/JOIN セクションが実行される際に、リモートサーバーに渡されるか、一時テーブルに保存できる最大サイズ（行数）。

max_sessions_for_user​

ClickHouseサーバーへの認証ユーザーごとの同時セッションの最大数。

例：

<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>
    <!-- User Alice can connect to a ClickHouse server no more than once at a time. -->
    <Alice>
        <profile>single_session_user</profile>
    </Alice>
    <!-- User Bob can use 2 simultaneous sessions. -->
    <Bob>
        <profile>two_sessions_profile</profile>
    </Bob>
    <!-- User Charles can use arbitrarily many of simultaneous sessions. -->
    <Charles>
        <profile>unlimited_sessions_profile</profile>
    </Charles>
</users>

可能な値：

• 正の整数
• 0 — 同時セッションの無限数（デフォルト）

max_size_to_preallocate_for_aggregation​

集約前にすべてのハッシュテーブルで事前に割り当てることが許可される要素数。

max_size_to_preallocate_for_joins​

結合前にすべてのハッシュテーブルで事前に割り当てることが許可される要素数。

max_streams_for_merge_tree_reading​

ゼロでない場合、MergeTreeテーブルの読み取りストリームの数を制限します。

max_streams_multiplier_for_merge_tables​

マージテーブルから読み取る際に、より多くのストリームを要求します。 ストリームは、マージテーブルが使用するテーブルに分配されます。これにより、スレッド間での作業の分配がより均等になり、マージテーブルがサイズの異なるテーブルの場合に特に有用です。

max_streams_to_max_threads_ratio​

スレッド数よりも多くのソースを使用できるため、作業をスレッド間でより均等に分配できます。これは、将来的には各ソースが自己選択して利用可能な作業を選べるようにできるため、暫定的なソリューションと見なされています。

max_subquery_depth​

クエリが指定された数を超える入れ子のサブクエリを持つ場合、例外をスローします。

max_table_size_to_drop​

クエリ時間内のテーブル削除に対する制限。値 0 は制限なしにすべてのテーブルを削除できることを意味します。

クラウドのデフォルト値：1TB。

max_temporary_columns​

クエリを実行する際にRAMに同時に保持しなければならない最大の一時カラムの数（定数カラムを含む）。 クエリの結果が中間計算の結果として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 パラメータを参照）を除外した最大のクエリ処理スレッド数。

このパラメータは、並行してクエリ処理パイプラインの同じ段階を実行するスレッドに適用されます。 例えば、テーブルから読み取る場合、関数を使って式を評価でき、WHEREでフィルタリングしつつ、少なくとも 'max_threads' 番号のスレッドを使ってGROUP BY のために前集計を行える場合は、 'max_threads' が使用されます。

LIMITのおかげで早く完了するクエリの場合、 'max_threads' を小さく設定し可能です。例えば、必要な数のエントリが各ブロックに位置していて、max_threads = 8 の場合、8ブロックが取得されますが、実際には1つだけで足りるでしょう。

max_threads の値が小さいほど、消費メモリは少なくなります。

クラウドのデフォルト値：auto(3)

max_threads_for_indexes​

インデックスを処理するための最大スレッド数。

max_untracked_memory​

小さな割り当ておよび解放は、スレッドローカル変数にグループ化され、指定された値を超えるとトラックまたはプロファイルされます。この値が 'memory_profiler_step' より高い場合、効果的に 'memory_profiler_step' に減少します。

memory_overcommit_ratio_denominator​

これは、グローバルレベルでハードリミットに達したときのソフトメモリ制限を表します。 この値は、クエリのためにオーバーコマット比を計算するために使用されます。 ゼロはクエリをスキップします。 メモリオーバーコミットについての詳細をお読みください。

memory_overcommit_ratio_denominator_for_user​

これは、ユーザーレベルでハードリミットに達したときのソフトメモリ制限を表します。 この値は、クエリのためにオーバーコマット比を計算するために使用されます。 ゼロはクエリをスキップします。 メモリオーバーコミットについての詳細をお読みください。

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​

ランダムなメモリ確保と解放を収集し、それを 'MemorySample' trace_type で system.trace_log に書き込みます。この確率は、確保のサイズに関係なく、すべてのアロケーション/フリーに対して適用されます（これは 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でのみ影響があります。MergeTreeテーブルのコンパクト部分のストライプ内でマルチバッファリーダーを使用するための粒子の数です。これにより、並列読み取りとプリフェッチがサポートされます。リモートファイルシステムから読み込む場合、マルチバッファリーダーの使用により読み取りリクエストの数が増加します。

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は両方のブロックを含むファイルの範囲を順次読み取ることで、余分なシークを回避します。

可能な値：

• 任意の正の整数。

merge_tree_min_bytes_per_task_for_remote_reading​

リモート読み込みのためのタスクごとに読み取る最小バイト数です。

merge_tree_min_read_task_size​

タスクサイズの厳格な下限（粒子の数が少なく、使用可能なスレッドの数が多くても、より小さなタスクを割り当てることはありません）。

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​

リモートファイルシステムから読み取る前に、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を読み込む際にファイルプレフィックスからカラムメタデータのキャッシュを有効にします。

merge_tree_use_prefixes_deserialization_thread_pool​

MergeTreeのワイドパーツにおける並列プレフィックス読み取りのためにスレッドプールの使用を有効にします。そのスレッドプールのサイズはサーバー設定 max_prefixes_deserialization_thread_pool_size により制御されます。

merge_tree_use_v1_object_and_dynamic_serialization​

有効にすると、MergeTreeでJSONおよびDynamicタイプのV1シリアル化バージョンが使用され、V2の代わりになります。この設定を変更するにはサーバーの再起動が必要です。

metrics_perf_events_enabled​

有効にすると、いくつかのperfイベントがクエリの実行全体にわたって測定されます。

metrics_perf_events_list​

クエリの実行全体にわたって測定されるperfメトリックのカンマ区切りリスト。空である場合はすべてのイベントを意味します。利用可能なイベントについてはソース内の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​

この設定は実験的です。カーネルからユーザースペースへのデータコピーなしで大きなファイルを読み込むための最小メモリ量を設定します。推奨される閾値は約64 MBです。なぜなら、mmap/munmap は遅いからです。大きなファイルのみに意味があり、データがページキャッシュ内にある場合にのみ役立ちます。

可能な値：

• 正の整数。
• 0 — 大きなファイルはカーネルからユーザースペースへのデータコピーのみで読まれます。

min_chunk_bytes_for_parallel_parsing​

• タイプ: unsigned int
• デフォルト値: 1 MiB

各スレッドが並行して解析する最小チャンクサイズ（バイト単位）。

min_compress_block_size​

MergeTree テーブル用。クエリを処理する際のレイテンシを削減するために、次のマークを書き込むときにブロックが圧縮され、サイズが少なくとも min_compress_block_size に達する場合です。デフォルトは65,536です。

未圧縮データが max_compress_block_size よりも小さい場合、ブロックの実際のサイズはこの値以上でなければならず、1つのマークに対するデータボリューム以上でなければなりません。

例を見てみましょう。 index_granularity が8192に設定されていると仮定します。

UInt32型のカラム（値ごとに4バイト）を書き込むと、8192行で合計32 KBのデータになります。min_compress_block_size = 65,536なので、2つのマークごとに圧縮ブロックが形成されます。

String型のURLカラム（値ごとに平均60バイト）を書き込むと、8192行で平均して500 KB未満のデータになります。65,536を超えるため、各マークごとに圧縮ブロックが形成されます。この場合、ディスクからのデータ読み取り時に、単一のマークの範囲内で追加のデータは解凍されません。

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​

行毎秒の最小実行速度。データブロックごとにチェックされる timeout_before_checking_execution_speed が切れるときにチェックされます。実行速度が低い場合は、例外がスローされます。

min_execution_speed_bytes​

秒あたりの実行バイト数の最小値。データブロックごとにチェックされる timeout_before_checking_execution_speed が切れるときにチェックされます。実行速度が低い場合は、例外がスローされます。

min_external_table_block_size_bytes​

外部テーブルに渡されるブロックを指定されたサイズバイトに圧縮します。ブロックが十分に大きくない場合に適用されます。

min_external_table_block_size_rows​

外部テーブルに渡されるブロックを指定されたサイズ行に圧縮します。ブロックが十分に大きくない場合に適用されます。

min_free_disk_bytes_to_perform_insert​

挿入を行うための最小の空きディスクスペースバイト数です。

min_free_disk_ratio_to_perform_insert​

挿入を行うための最小の空きディスクスペース比率です。

min_free_disk_space_for_temporary_data​

外部ソートおよび集計に使用される一時データを書く際に保持する最小ディスクスペースです。

min_hit_rate_to_use_consecutive_keys_optimization​

集約における連続キー最適化のために使用されるキャッシュの最小ヒット率。

min_insert_block_size_bytes​

INSERT クエリによってテーブルに挿入できるブロック内の最小バイト数を設定します。より小さいサイズのブロックは、より大きなものに圧縮されます。

可能な値：

• 正の整数。
• 0 — 圧縮無効。

min_insert_block_size_bytes_for_materialized_views​

INSERT クエリによってテーブルに挿入できるブロック内の最小バイト数を設定します。より小さいサイズのブロックは、より大きなものに圧縮されます。この設定は materialized view に挿入されるブロックにのみ適用されます。この設定を調整することで、マテリアライズドビューにプッシュする際のブロック圧縮を制御し、過剰なメモリ使用を回避できます。

可能な値：

• 任意の正の整数。
• 0 — 圧縮無効。

関連情報

• min_insert_block_size_bytes

min_insert_block_size_rows​

INSERT クエリによってテーブルに挿入できるブロック内の最小行数を設定します。より小さいサイズのブロックは、より大きなものに圧縮されます。

可能な値：

• 正の整数。
• 0 — 圧縮無効。

min_insert_block_size_rows_for_materialized_views​

INSERT クエリによってテーブルに挿入できるブロック内の最小行数を設定します。より小さいサイズのブロックは、より大きなものに圧縮されます。この設定は materialized view に挿入されるブロックにのみ適用されます。この設定を調整することで、マテリアライズドビューにプッシュする際のブロック圧縮を制御し、過剰なメモリ使用を回避できます。

可能な値：

• 任意の正の整数。
• 0 — 圧縮無効。

関連情報

• min_insert_block_size_rows

min_joined_block_size_bytes​

JOIN入力および出力ブロックの最小ブロックサイズ（結合アルゴリズムがサポートしている場合）。小さなブロックは圧縮されます。0は無制限を意味します。

min_joined_block_size_rows​

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. スピンロック競合で無駄なCPUサイクルが浪費され（native_queued_spin_lock_slowpath）、効率が低下します。
3. CPU利用率が低下し、並列性とスループットが制限されます。

Resizeノードの分割方法​

1. スプリットが可能であることを確認するために、出力ストリームの数がチェックされます：各スプリットプロセッサの出力ストリームは min_outstreams_per_resize_after_split の閾値を満たしているかそれを超えています。
2. Resizeノードは、ポート数が等しい小さな Resizeノードに分割され、それぞれが入力と出力ストリームのサブセットを処理します。
3. 各グループが独立して処理され、ロック競合が減少します。

入出力が任意のResizeノードでの分割​

分割されたResizeノードの数で割り切れない入出力がある場合、いくつかの入力がNullSourceに接続され、いくつかの出力がNullSinkに接続されます。これにより、全体のデータフローに影響を与えることなく、分割を行うことができます。

設定の目的​

min_outstreams_per_resize_after_split 設定は、Resizeノードの分割が意味のあるものであることを保証し、あまりにも少ないストリームの作成を避けることで、非効率な並列処理につながることを防ぎます。出力ストリームの最小数を強制することで、この設定はストリームの分割とマージに関与するシナリオでクエリ実行の最適化を支援します。

設定を無効にする​

Resizeノードの分割を無効にするには、この設定を0に設定します。これにより、パイプライン生成中にResizeノードの分割が抑制され、元の構造を保持したまま保持されます。

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​

複数の結合の書き換え時に、最上位の式リストにエイリアスを追加しない。

mutations_execute_nondeterministic_on_initiator​

真の場合、定数の非決定論的関数（例えば、now()関数）はイニシエーターで実行され、UPDATEおよびDELETEクエリ内のリテラルに置き換えられます。これは、定数の非決定論的関数を使用して変異を実行する際に、レプリカ間のデータを同期させるのに役立ちます。デフォルト値：false。

mutations_execute_subqueries_on_initiator​

真の場合、スカラーサブクエリはイニシエーターで実行され、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）同期的に実行することを許可します。

可能な値：

mysql_datatypes_support_level​

MySQL型が対応するClickHouse型にどのように変換されるかを定義します。カンマ区切りリストで、decimal、datetime64、 date2Date32 または date2Stringの組み合わせで指定します。

• decimal: 精度が許す場合、NUMERICおよびDECIMAL型をDecimalに変換します。
• datetime64: 精度が0でない場合、DATETIMEおよびTIMESTAMP型を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ワイヤプロトコルを介して接続された場合にのみ有効です。

• 0 - BLOBを使用。
• 1 - TEXTを使用。

mysql_map_string_to_text_in_show_columns​

有効にすると、String ClickHouseデータ型は、SHOW COLUMNSでTEXTとして表示されます。

これはMySQLワイヤプロトコルを介して接続された場合にのみ有効です。

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

変異したテーブルに未完成の変異がこの数以上ある場合、「Too many mutations ...」例外をスローします。0 - 無効。

odbc_bridge_connection_pool_size​

ODBCブリッジ内の各接続設定文字列の接続プールサイズです。

odbc_bridge_use_connection_pooling​

ODBCブリッジ内で接続プールを使用します。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_trace_probability​

ClickHouseが実行されたクエリのトレースを開始する確率を設定します（親 trace context が供給されていない場合）。

可能な値：

• 0 — すべての実行されたクエリのトレースが無効になります（親トレースコンテキストが供給されていない場合）。
• [0..1] の範囲内の正の浮動小数点数。たとえば、設定値が 0.5 の場合、ClickHouseはクエリの半分に対して平均的にトレースを開始できます。
• 1 — すべての実行されたクエリのトレースが有効になります。

opentelemetry_trace_cpu_scheduling​

ワークロードの先取的CPUスケジューリングのためにOpenTelemetryのスパンを収集します。

opentelemetry_trace_processors​

プロセッサのOpenTelemetryスパンを収集します。

optimize_aggregation_in_order​

MergeTreeテーブルのデータを対応する順序で集約するためのGROUP BY最適化を有効にします。

可能な値：

• 0 — GROUP BY最適化は無効です。
• 1 — GROUP BY最適化は有効です。

関連情報

• GROUP BY最適化

optimize_aggregators_of_group_by_keys​

SELECTセクション内のGROUP BYキーの最小/最大/任意/任意最後の集約器を排除します。

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

異なる入力形式からの行数カウントの最適化を有効または無効にします。これはテーブル関数/エンジン file/s3/url/hdfs/azureBlobStorage に適用されます。

可能な値:

• 0 — 最適化無効。
• 1 — 最適化有効。

optimize_distinct_in_order​

DISTINCT の最適化を有効にし、一部のカラムが並べ替えの接頭辞を形成する場合に適用します。例えば、マージツリーや 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_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) に書き換えることができ、これにより次のことが可能になります:

• 単純なフィルタリング式でのインデックスの利用
• クロスから内部結合の最適化

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 の文字列型引数を enum に置き換えます。これは、分散クエリで不整合を引き起こす可能性があるため、デフォルトでは無効になっています。

optimize_injective_functions_in_group_by​

GROUP BY セクションで引数に対して射影関数を置き換えます。

optimize_injective_functions_inside_uniq​

uniq*() 関数内の1引数の射影関数を削除します。

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() と同義の形式に書き換えます。

optimize_on_insert​

挿入の前にデータ変換を有効または無効にします。これは、テーブルエンジンに基づいてこのブロックでマージが行われたかのように動作します。

可能な値:

• 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_qbit_distance_function_reads​

QBit データ型の距離関数を、計算に必要なカラムだけをストレージから読み取る同等の関数に置き換えます。

optimize_read_in_order​

MergeTree テーブルからデータを読み取るためのORDER BY最適化を有効にします。

可能な値:

• 0 — ORDER BY 最適化無効。
• 1 — ORDER BY 最適化有効。

参照

• ORDER BY Clause

optimize_read_in_window_order​

ウィンドウクローズでのデータを対応する順序で読み取るための 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​

条件式を引数として持つ集約関数を論理的に等価な場合に書き換えます。例えば、avg(if(cond, col, null)) は avgOrNullIf(cond, col) に書き換えることができます。これによりパフォーマンスが向上する可能性があります。

optimize_rewrite_array_exists_to_has​

論理的に等価な場合、arrayExists() 関数を has() に書き換えます。例えば、arrayExists(x -> x = 1, arr) は has(arr, 1) に書き換えることができます。

optimize_rewrite_regexp_functions​

正規表現に関連する関数をよりシンプルで効率的な形式に書き換えます。

optimize_rewrite_sum_if_to_count_if​

sumIf() と sum(if()) 関数を、論理的に等価な場合に countIf() 関数に書き換えます。

optimize_skip_merged_partitions​

OPTIMIZE TABLE ... FINAL クエリの最適化を有効または無効にします。レベルが > 0 のパートが1つだけあり、期限切れの TTL がない場合にこの設定が適用されます。

• OPTIMIZE TABLE ... FINAL SETTINGS optimize_skip_merged_partitions=1

デフォルトでは、OPTIMIZE TABLE ... FINAL クエリは、パートが1つだけの場合でも、そのパートを再書き込みます。

可能な値:

• 1 - 最適化を有効にする。
• 0 - 最適化を無効にする。

optimize_skip_unused_shards​

SELECT クエリの未使用のシャードをスキップすることを有効または無効にします。これは、WHERE/PREWHERE に sharding key 条件がある場合に適用されます（データが sharding key に従って分散されていると仮定します。そうでない場合、クエリは不正確な結果を返します）。

可能な値:

• 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 テーブルも見る Distributed テーブルがある場合）に依存します。

可能な値:

• 0 — 無効、optimize_skip_unused_shards は常に機能します。
• 1 — 1 階層目のみに対して optimize_skip_unused_shards を有効にします。
• 2 — 2 階層目まで optimize_skip_unused_shards を有効にします。

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​

同一の引数を持つ集約関数を融合できるようにします。これは、同一の引数を持つ少なくとも2つの集約関数を sum、count、または avg から sumCount に書き換えます。

可能な値:

• 0 — 同一の引数を持つ関数は融合されません。
• 1 — 同一の引数を持つ関数が融合されます。

例

クエリ:

CREATE TABLE fuse_tbl(a Int8, b Int8) Engine = Log;
SET optimize_syntax_fuse_functions = 1;
EXPLAIN SYNTAX SELECT sum(a), sum(b), count(b), avg(b) from fuse_tbl FORMAT TSV;

結果:

SELECT
    sum(a),
    sumCount(b).1,
    sumCount(b).2,
    (sumCount(b).1) / (sumCount(b).2)
FROM fuse_tbl

optimize_throw_if_noop​

OPTIMIZE クエリがマージを実行しなかった場合に例外をスローすることを有効または無効にします。

デフォルトでは、OPTIMIZE は何もしなかった場合でも正常に返します。この設定により、これらの状況を区別し、例外メッセージで理由を取得できます。

可能な値:

• 1 — 例外をスローすることが有効です。
• 0 — 例外をスローすることが無効です。

optimize_time_filter_with_preimage​

日付および日時の述語を最適化し、関数を変換なしの等価比較に変換します (例: toYear(col) = 2023 -> col >= '2023-01-01' AND col <= '2023-12-31')

optimize_trivial_approximate_count_query​

エンベデッドRocksDBのようなそのような推定をサポートするストレージの単純なカウント最適化に対して近似値を使用します。

可能な値:

• 0 — 最適化無効。
• 1 — 最適化有効。

optimize_trivial_count_query​

SELECT count() FROM table の単純なクエリの最適化を有効または無効にします。行レベルのセキュリティを使用する必要がある場合は、この設定を無効にします。

可能な値:

• 0 — 最適化無効。
• 1 — 最適化有効。

参照もしてください:

• optimize_functions_to_subcolumns

optimize_trivial_insert_select​

単純な 'INSERT INTO table SELECT ... FROM TABLES' クエリを最適化します。

optimize_uniq_to_count​

uniq およびその変種（uniqUpTo を除く）を、サブクエリに DISTINCT または GROUP BY 句がある場合に count へ書き換えます。

optimize_use_implicit_projections​

SELECT クエリを実行するために暗黙の射影を自動的に選択します。

optimize_use_projection_filtering​

SELECT クエリを実行するために射影を使用して部分範囲をフィルタリングすることを有効にします。射影が選択されていない場合でも適用されます。

optimize_use_projections​

projection の最適化を実行する際に有効または無効にします。

可能な値:

• 0 — 射影の最適化無効。
• 1 — 射影の最適化有効。

optimize_using_constraints​

クエリ最適化のために制約を使用します。デフォルトは false です。

可能な値:

• true, false

os_threads_nice_value_materialized_view​

マテリアライズドビューのスレッドの Linux nice 値。低い値は高い CPU 優先度を意味します。

CAP_SYS_NICE 権限が必要です。そうでなければ無効です。

可能な値: -20 から 19。

os_threads_nice_value_query​

クエリプロセッシングスレッドの Linux nice 値。低い値は高い CPU 優先度を意味します。

CAP_SYS_NICE 権限が必要です。そうでなければ無効です。

可能な値: -20 から 19。

output_format_compression_level​

クエリの出力が圧縮されている場合のデフォルトの圧縮レベル。この設定は、SELECT クエリが INTO OUTFILE を持つ場合、またはテーブル関数 file、url、hdfs、s3、または azureBlobStorage に書き込むときに適用されます。

可能な値: 1 から 22

output_format_compression_zstd_window_log​

出力圧縮方式が zstd の場合に使用できます。値が 0 より大きい場合、この設定は圧縮ウィンドウサイズ（ 2 の冪）を明示的に設定し、zstd 圧縮の長距離モードを有効にします。これにより、より良い圧縮率を達成できる可能性があります。

可能な値: 非負の数。値が小さすぎるか大きすぎる場合、zstdlib は例外をスローします。典型的な値は、20（ウィンドウサイズ = 1MB）から 30（ウィンドウサイズ = 1GB）です。

output_format_parallel_formatting​

データフォーマットの並列フォーマットを有効または無効にします。これは、TSV、TSKV、CSV および JSONEachRow 形式にのみサポートされています。

可能な値:

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

page_cache_block_size​

ユーザースペースのページキャッシュに格納するファイルチャンクのサイズ（バイト単位）。キャッシュを通るすべての読み取りは、このサイズの倍数に切り上げられます。

この設定はクエリごとに調整できますが、異なるブロックサイズのキャッシュエントリは再利用できません。この設定を変更すると、既存のキャッシュエントリが無効になります。

1 MiB のような高い値は高スループットのクエリに適しており、64 KiB のような低い値は低レイテンシのポイントクエリに適しています。

page_cache_inject_eviction​

ユーザースペースのページキャッシュは、時折、ランダムにいくつかのページを無効にします。テスト用です。

page_cache_lookahead_blocks​

ユーザースペースのページキャッシュミス時に、キャッシュにも含まれていない場合には、基盤ストレージからこの数の連続ブロックを一度に読み取ります。各ブロックは page_cache_block_size バイトです。

高い値は高スループットのクエリに適しており、低レイテンシのポイントクエリはリードアヘッドなしでより良く動作します。

parallel_distributed_insert_select​

並列の分散 INSERT ... SELECT クエリを有効にします。

INSERT INTO distributed_table_a SELECT ... FROM distributed_table_b クエリを実行し、両方のテーブルが同じクラスターを使用し、かつ両方のテーブルがレプリケートされたまたは非レプリケートされたものである場合、このクエリはすべてのシャードでローカルに処理されます。

可能な値:

• 0 — 無効。
• 1 — SELECT は分散エンジンの基盤テーブルの各シャードで実行されます。
• 2 — SELECT と INSERT は分散エンジンの基盤テーブルの各シャードで実行されます。

この設定を使用する場合は、enable_parallel_replicas = 1 の設定が必要です。

parallel_hash_join_threshold​

ハッシュベースの結合アルゴリズムが適用されたとき、このしきい値は hash と parallel_hash を使い分けるために役立ちます（右テーブルサイズの推定値が利用可能な場合のみ）。前者は、右テーブルサイズがしきい値以下であることが分かっているときに使用されます。

parallel_replica_offset​

これは内部設定であり、直接使用するべきではなく、'parallel replicas' モードの実装の詳細を表します。この設定は、並列レプリカのクエリ処理に参加するレプリカのインデックスのために、イニシエーターサーバーによって自動的に設定されます。

parallel_replicas_allow_in_with_subquery​

true に設定すると、IN のサブクエリは各フォロワーレプリカで実行されます。

parallel_replicas_connect_timeout_ms​

クエリ実行中に並列レプリカに接続するためのタイムアウト（ミリ秒単位）。タイムアウトが切れると、該当するレプリカはクエリ実行に使用されません。

parallel_replicas_count​

これは内部設定であり、直接使用するべきではなく、'parallel replicas' モードの実装の詳細を表します。この設定は、並列レプリカのクエリ処理に参加する並列レプリカの数のために、イニシエーターサーバーによって自動的に設定されます。

parallel_replicas_custom_key​

特定のテーブルの作業をレプリカ間で分割するために使用できる任意の整数式。値は任意の整数式にできます。

主キーを使用した単純な式が望ましいです。

この設定が、複数のレプリカを持つ単一のシャードで構成されるクラスターで使用されると、これらのレプリカはバーチャルシャードに変換されます。

そうでなければ、SAMPLE キーと同じように動作し、各シャードの複数のレプリカを使用します。

parallel_replicas_custom_key_range_lower​

カスタム範囲 [parallel_replicas_custom_key_range_lower, INT_MAX] に基づいて、フィルタータイプ range がレプリカ間で作業を均等に分割できるようにします。

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​

カスタム範囲 [0, parallel_replicas_custom_key_range_upper] に基づいて、フィルタータイプ range がレプリカ間で作業を均等に分割できるようにします。0 の値は上限を無効にし、カスタムキー式の最大値を設定します。

parallel_replicas_custom_key_range_lower と組み合わせて使用すると、範囲 [parallel_replicas_custom_key_range_lower, parallel_replicas_custom_key_range_upper] に対して作業を均等に分割できます。

注意: この設定は、クエリ処理中に追加のデータをフィルタリングすることはなく、範囲フィルターが並列処理のために範囲 [0, INT_MAX] を分割するポイントを変更します。

parallel_replicas_for_cluster_engines​

テーブル関数エンジンをそのクラスター代替品で置き換えます。

parallel_replicas_for_non_replicated_merge_tree​

true に設定すると、ClickHouse は非レプリケートの MergeTree テーブルに対しても並列レプリカアルゴリズムを使用します。

parallel_replicas_index_analysis_only_on_coordinator​

インデックス分析はレプリカコーディネーターのみで行われ、他のレプリカではスキップされます。これは、parallel_replicas_local_plan が有効な場合にのみ有効です。

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​

カスタムキーで並列レプリカと一緒に使用するフィルターのタイプ。デフォルト - カスタムキーに対して剰余演算を使用、範囲 - カスタムキーに対して値のタイプのすべての可能な値を使用した範囲フィルターを使用します。

parallel_replicas_only_with_analyzer​

並列レプリカを使用するには、アナライザーを有効にする必要があります。アナライザーが無効の場合、クエリ実行はローカル実行にフォールバックされます。並列読み取りが有効になっていてもこれは同様です。アナライザーが無効な状態での並列レプリカの使用はサポートされません。

parallel_replicas_prefer_local_join​

true に設定すると、JOIN が並列レプリカアルゴリズムで実行できる場合、右 JOIN パートのすべてのストレージが *MergeTree の場合、ローカル JOIN が使用され、GLOBAL JOIN の代わりとなります。

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' は、単一桁の日付がスペースでパディングされることを期待しています。例えば、' 2' は受け入れられますが、'2' はエラーを引き起こします。

parsedatetime_parse_without_leading_zeros​

関数 'parseDateTime' のフォーマッタ '%c', '%l' および '%k' は、先頭ゼロなしで月と時間を解析します。

partial_merge_join_left_table_buffer_bytes​

0 でない場合、部分マージJOINの左側テーブルのために、左テーブルブロックを大きなものにグループ化します。結合スレッドごとに最大2倍のメモリを使用します。

partial_merge_join_rows_in_right_blocks​

部分マージ結合アルゴリズムにおける右側結合データブロックのサイズを制限します。JOIN クエリ用です。

ClickHouseサーバー:

1. 右側結合データを指定された行数までのブロックに分割します。
2. 各ブロックの最小値と最大値でインデックスを作成します。
3. 可能であれば、準備されたブロックをディスクにアンロードします。

可能な値:

• 任意の正の整数。推奨値の範囲: [1000, 100000]。

partial_result_on_first_cancel​

キャンセル後に部分結果を返すことを許可します。

parts_to_delay_insert​

宛先テーブルに単一パーティション内にアクティブなパーツがてんこ盛りである場合、テーブルへの挿入を人工的に遅延させます。

parts_to_throw_insert​

宛先テーブルの単一パーティション内にアクティブなパーツがこの数を超える場合、「パーツが多すぎます…」例外をスローします。

per_part_index_stats​

各パーツのインデックス統計をログします。

periodic_live_view_refresh​

定期的に更新されるライブビューが強制的に更新される間隔。

poll_interval​

サーバーで指定された秒数の間、クエリ待機ループをブロックします。

postgresql_connection_attempt_timeout​

PostgreSQLエンドポイントへの接続試行の接続タイムアウト（秒単位）。 この値は接続URLの connect_timeout パラメータとして渡されます。

postgresql_connection_pool_auto_close_connection​

接続をプールに戻す前に接続を閉じます。

postgresql_connection_pool_retries​

PostgreSQLテーブルエンジンおよびデータベースエンジン向けの接続プールのプッシュ/ポップリトライ回数。

postgresql_connection_pool_size​

PostgreSQLテーブルエンジンおよびデータベースエンジンの接続プールサイズ。

postgresql_connection_pool_wait_timeout​

PostgreSQLテーブルエンジンおよびデータベースエンジンの空プールでの接続プールのプッシュ/ポップタイムアウト。デフォルトでは空プールでブロックされます。

postgresql_fault_injection_probability​

内部（レプリケーション用）PostgreSQLクエリが失敗する確率の近似値。有効値は [0.0f, 1.0f] の範囲です。

prefer_column_name_to_alias​

クエリの式や句の中でエイリアスではなく元のカラム名を使用することを有効または無効にします。特にエイリアスがカラム名と同じ場合に重要です。式エイリアスを参照してください。この設定を有効にすると、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​

外部ソートの最大ブロックサイズを優先し、マージ中のメモリ使用量を削減します。