メインコンテンツまでスキップ
バージョン: 26.2 Preview

システム変数

StarRocks は、多くのシステム変数を提供しており、要件に応じて設定や変更が可能です。このセクションでは、StarRocks がサポートする変数について説明します。これらの変数の設定を確認するには、MySQL クライアントで SHOW VARIABLES コマンドを実行します。また、SET コマンドを使用して、変数を動的に設定または変更することもできます。これらの変数は、システム全体でグローバルに、現在のセッションのみで、または単一のクエリ文でのみ有効にすることができます。

StarRocks の変数は、MySQL の変数セットを参照していますが、一部の変数は MySQL クライアントプロトコルとの互換性のみを持ち、MySQL データベースでは機能しません。

注意

どのユーザーでも SHOW VARIABLES を実行し、セッションレベルで変数を有効にする権限があります。ただし、SYSTEM レベルの OPERATE 権限を持つユーザーのみが、変数をグローバルに有効にすることができます。グローバルに有効な変数は、すべての将来のセッション（現在のセッションを除く）で有効になります。

現在のセッションの設定変更を行い、さらにその設定変更をすべての将来のセッションに適用したい場合は、GLOBAL 修飾子を使用せずに一度、使用してもう一度変更を行うことができます。例：

SET query_mem_limit = 137438953472; -- 現在のセッションに適用。
SET GLOBAL query_mem_limit = 137438953472; -- すべての将来のセッションに適用。

変数の階層と種類​

StarRocks は、グローバル変数、セッション変数、SET_VAR ヒントの3種類（レベル）の変数をサポートしています。それらの階層関係は次のとおりです：

  • グローバル変数はグローバルレベルで有効であり、セッション変数や SET_VAR ヒントによって上書きされることがあります。
  • セッション変数は現在のセッションでのみ有効であり、SET_VAR ヒントによって上書きされることがあります。
  • SET_VAR ヒントは、現在のクエリ文でのみ有効です。

変数の表示​

SHOW VARIABLES [LIKE 'xxx'] を使用して、すべてまたは一部の変数を表示できます。例：

-- システム内のすべての変数を表示。
SHOW VARIABLES;

-- 特定のパターンに一致する変数を表示。
SHOW VARIABLES LIKE '%time_zone%';

変数の設定​

変数をグローバルまたは単一のセッションで設定​

変数を グローバルに または 現在のセッションのみで 有効に設定できます。グローバルに設定すると、新しい値はすべての将来のセッションで使用されますが、現在のセッションは元の値を使用します。「現在のセッションのみ」に設定すると、変数は現在のセッションでのみ有効になります。

SET <var_name> = xxx; で設定された変数は、現在のセッションでのみ有効です。例：

SET query_mem_limit = 137438953472;

SET forward_to_master = true;

SET time_zone = "Asia/Shanghai";

SET GLOBAL <var_name> = xxx; で設定された変数はグローバルに有効です。例：

SET GLOBAL query_mem_limit = 137438953472;

以下の変数はグローバルにのみ有効です。単一のセッションで有効にすることはできません。これらの変数には SET GLOBAL <var_name> = xxx; を使用する必要があります。単一のセッションでそのような変数を設定しようとすると（SET <var_name> = xxx;）、エラーが返されます。

  • activate_all_roles_on_login
  • character_set_database
  • cngroup_low_watermark_cpu_used_permille
  • cngroup_low_watermark_running_query_count
  • cngroup_resource_usage_fresh_ratio
  • cngroup_schedule_mode
  • default_rowset_type
  • enable_reduce_cast_varchar_expr_sync_type
  • enable_reduce_cast_varchar_length_inheritance
  • enable_group_level_query_queue
  • enable_query_history
  • enable_query_queue_load
  • enable_query_queue_select
  • enable_query_queue_statistic
  • enable_table_name_case_insensitive
  • enable_tde
  • init_connect
  • language
  • license
  • lower_case_table_names
  • performance_schema
  • query_cache_size
  • query_history_keep_seconds
  • query_history_load_interval_seconds
  • query_queue_concurrency_limit
  • query_queue_cpu_used_permille_limit
  • query_queue_driver_high_water
  • query_queue_driver_low_water
  • query_queue_fresh_resource_usage_interval_ms
  • query_queue_max_queued_queries
  • query_queue_mem_used_pct_limit
  • query_queue_pending_timeout_second
  • system_time_zone
  • version
  • version_comment

さらに、変数設定は定数式もサポートしています。例：

SET query_mem_limit = 10 * 1024 * 1024 * 1024;
SET forward_to_master = concat('tr', 'u', 'e');

単一のクエリ文で変数を設定​

特定のクエリに対して変数を設定する必要がある場合があります。SET_VAR ヒントを使用することで、単一の文内でのみ有効なセッション変数を設定できます。

StarRocks は、以下の文で SET_VAR の使用をサポートしています：

  • SELECT
  • INSERT (v3.1.12 および v3.2.0 以降)
  • UPDATE (v3.1.12 および v3.2.0 以降)
  • DELETE (v3.1.12 および v3.2.0 以降)

SET_VAR は、上記のキーワードの後にのみ配置され、/*+...*/ で囲まれます。

例：

SELECT /*+ SET_VAR(query_mem_limit = 8589934592) */ name FROM people ORDER BY name;

SELECT /*+ SET_VAR(query_timeout = 1) */ sleep(3);

UPDATE /*+ SET_VAR(insert_timeout=100) */ tbl SET c1 = 2 WHERE c1 = 1;

DELETE /*+ SET_VAR(query_mem_limit = 8589934592) */
FROM my_table PARTITION p1
WHERE k1 = 3;

INSERT /*+ SET_VAR(insert_timeout = 10000000) */
INTO insert_wiki_edit
    SELECT * FROM FILES(
        "path" = "s3://inserttest/parquet/insert_wiki_edit_append.parquet",
        "format" = "parquet",
        "aws.s3.access_key" = "XXXXXXXXXX",
        "aws.s3.secret_key" = "YYYYYYYYYY",
        "aws.s3.region" = "us-west-2"
);

単一の文で複数の変数を設定することもできます。例：

SELECT /*+ SET_VAR
  (
  exec_mem_limit = 515396075520,
  query_timeout=10000000,
  batch_size=4096,
  parallel_fragment_exec_instance_num=32
  )
  */ * FROM TABLE;

ユーザーのプロパティとして変数を設定​

ALTER USER を使用して、セッション変数をユーザーのプロパティとして設定できます。この機能は v3.3.3 からサポートされています。

例：

-- ユーザー jack に対してセッション変数 `query_timeout` を `600` に設定。
ALTER USER 'jack' SET PROPERTIES ('session.query_timeout' = '600');

変数の説明​

変数は アルファベット順 に説明されています。global ラベルが付いた変数はグローバルにのみ有効です。他の変数はグローバルまたは単一のセッションで有効にすることができます。

activate_all_roles_on_login (global)​

  • 説明: StarRocks ユーザーが StarRocks クラスタに接続する際に、すべてのロール（デフォルトロールと付与されたロールを含む）を有効にするかどうか。
    • 有効にすると（true）、ユーザーのすべてのロールがログイン時にアクティブになります。これは SET DEFAULT ROLE で設定されたロールよりも優先されます。
    • 無効にすると（false）、SET DEFAULT ROLE で設定されたロールがアクティブになります。
  • デフォルト: false
  • 導入バージョン: v3.0

セッションで割り当てられたロールをアクティブにしたい場合は、SET ROLE コマンドを使用してください。

ann_params​

  • 説明: 近似最近傍（ANN）ベクターインデックス検索のクエリパラメータを指定します。値は、キーと値がともに文字列である JSON オブジェクト文字列です。HNSW は efsearch、IVFPQ は nprobe、max_codes、scan_table_threshold、polysemous_ht、range_search_confidence をサポートします。セッションまたは単一ステートメントに設定できます。例：SET ann_params = '{"efsearch":"256"}' または SET_VAR (ann_params='{"efsearch":"256"}')。
  • デフォルト: ""
  • データ型: String
  • スコープ: Session

array_low_cardinality_optimize​

  • スコープ: Session
  • 説明: オプティマイザが array<varchar> カラムを low-cardinality（辞書ベース）のデコードおよび関連最適化の対象として検討するかどうかを制御します。有効にすると、オプティマイザの low-cardinality ルール（例: DecodeCollector）は辞書カラムを定義し、型が varchar または array<varchar> の式に対して辞書デコードを適用することがあります。無効にすると、スカラーの varchar カラムのみが対象となり、array<varchar> 型はこれらの low-cardinality 最適化によって無視されます。この変数は配列サポートの判定に DecodeCollector.supportAndEnabledLowCardinality(...) によって読み取られ、SessionVariable の getter/setter を介して公開されます。
  • デフォルト: true
  • タイプ: boolean
  • 導入バージョン: v3.3.0, v3.4.0, v3.5.0

auto_increment_increment​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

avro_use_jni_reader​

  • スコープ: Session

  • 説明: Hive などの外部 Catalog にある Avro データをスキャンする際に、JNI ベースの Avro Reader を使用するかどうかを制御します。有効にすると（true）、StarRocks は JNI Reader を使用します。無効にすると（false）、StarRocks はネイティブ Avro Reader を使用します。現在この変数は主に互換性確保のためのフォールバックとして利用されます。デフォルト値は false のため、既定ではネイティブ Avro Reader が使用されます。

    現在の注意点:

    • ネイティブ Avro Reader と JNI Reader は、CHAR(n) の挙動について現在は整合しています。この整合は #73579 で反映されており、この点では native と JNI の動作は一致しています。
    • ネイティブ Avro Reader は現在 null、deflate、snappy のみをサポートしており、bzip2 などその他の codec はサポートしていません。ネイティブ Reader がサポートしていない codec を扱う必要がある場合は、JNI Reader を手動で有効にしてください。

  • デフォルト: false

  • データ型: boolean

  • 導入バージョン: v4.1.1

binary_encoding_format​

  • スコープ: Session
  • 説明: StarRocks が MySQL テキスト結果で BINARY / VARBINARY の値をどのようにエンコードするかを制御します。指定可能な値は raw、hex、base64 で、デフォルトは hex です。この変数は binary_encoding_level と組み合わせて動作します。トップレベルのバイナリ値は MySQL クライアントがそのまま扱える場合がありますが、ARRAY、MAP、STRUCT などのネストした型の中にあるバイナリ値は JSON ライクな文字列として返されるため、表示可能で整った形式を保つには追加のエンコードが必要になることがあります。よりコンパクトな表現が必要な場合は base64 を、追加エンコードを無効にしたい場合は raw を使用します。
  • デフォルト: hex
  • データ型: String
  • 導入バージョン: v4.1

binary_encoding_level​

  • スコープ: Session
  • 説明: MySQL テキスト結果でどのバイナリ値をエンコードするかを制御します。指定可能な値は nested と all で、デフォルトは nested です。nested は既存互換性のための設定で、ARRAY、MAP、STRUCT などのネストした型の中にあるバイナリ値のみをエンコードし、トップレベルのバイナリ列の挙動は従来のまま維持します。すべてのバイナリ出力を統一した形式にしたい場合は all を使用すると、トップレベルのバイナリ値もエンコードされます。binary_encoding_format = raw の場合は、ここで nested または all を指定していても追加のバイナリエンコードは行われないため、ネスト結果の可読性が下がることがあります。
  • デフォルト: nested
  • データ型: String
  • 導入バージョン: v4.1

big_query_profile_threshold​

  • 説明: 大規模なクエリのしきい値を設定するために使用されます。セッション変数 enable_profile が false に設定されており、クエリの実行時間が変数 big_query_profile_threshold で指定されたしきい値を超えた場合、そのクエリのプロファイルが生成されます。

    注: v3.1.5 から v3.1.7、および v3.2.0 から v3.2.2 では、大規模なクエリのしきい値を設定するために big_query_profile_second_threshold を導入しました。v3.1.8、v3.2.3、およびそれ以降のリリースでは、このパラメータは big_query_profile_threshold に置き換えられ、より柔軟な設定オプションを提供します。

  • デフォルト: 0

  • 単位: 秒

  • データ型: 文字列

  • 導入バージョン: v3.1

blacklist_backup_routing​

  • スコープ: Session
  • 説明: 共有データ（shared-data）モードでは、スキャンに対してプランが優先する compute node が、現在のクエリで利用可能なワーカーに含まれない場合（例：ノードがダウンしている、またはホストの blocklist に載っているなど）、プランナーはバックアップ用の compute node を選ぶ必要があります。この変数は、（プライマリ以外の）候補ノードのうち、バックアップをどのように選ぶかを設定します。RANDOM は候補集合から一様乱択でサンプリングします。CIRCULAR はプライマリからソート済みの compute node ID のリング上を走査し、最初に見つかった候補ノードを選びます（決定的）。バックアップとして選べるノードは skip_black_list にも依存します。デフォルトではホスト blocklist 上のノードは除外されます。skip_black_list が true の場合、blocklist に載っていても、（例：生存しておりウェアハウスで利用可能など）他の条件を満たせばバックアップとして選ばれることがあります。
  • デフォルト: CIRCULAR
  • データ型: String
  • 有効な値: CIRCULAR, RANDOM
  • 導入バージョン: -

bm25_b​

  • スコープ: Session
  • 説明: builtin GIN 全文検索の score() 関連性ランキングで使う BM25 の長さ正規化パラメータ b。値が大きいほど長いドキュメントへのペナルティが強くなります。範囲は [0, 1] である必要があります。
  • デフォルト: 0.75
  • データ型: Double
  • 導入バージョン: -

bm25_k1​

  • スコープ: Session
  • 説明: builtin GIN 全文検索の score() 関連性ランキングで使う BM25 の語頻度飽和パラメータ k1。値が大きいほど、繰り返される語がスコアを増加させ続けます。有限かつ非負の数である必要があります。
  • デフォルト: 1.2
  • データ型: Double
  • 導入バージョン: -

catalog​

  • 説明: セッションが属するカタログを指定するために使用されます。
  • デフォルト: default_catalog
  • データ型: 文字列
  • 導入バージョン: v3.2.4

cbo_cte_force_reuse_node_count​

  • 説明: Common Table Expressions (CTE) に対するオプティマイザのショートカットを制御するセッションスコープの閾値。RelationTransformer.visitCTE 内でプランナは CTE プロデューサーツリーのノード数をカウントします（cteContext.getCteNodeCount）。そのカウントがこの閾値以上かつ閾値が 0 より大きい場合、transformer は CTE の再利用を強制します：プロデューサープランのインライン化／変換をスキップし、事前計算された式マッピング（入力なし）で consume 演算子を構築し、代わりに生成されたカラム参照を使用します。これにより非常に大きな CTE プロデューサーツリーに対するオプティマイザの時間を削減できますが、物理プランの最適性が若干低下する可能性があります。値を 0 に設定すると force-reuse 最適化が無効になります。この変数は SessionVariable に getter/setter があり、セッション単位で適用されます。
  • スコープ: Session
  • デフォルト: 2000
  • タイプ: int
  • 導入バージョン: v3.5.3

cbo_cte_reuse​

  • 説明: オプティマイザが共通テーブル式（CTE）を再利用して multi-distinct 集計クエリを書き換えることを許可するかを制御します（CBO の CTE 再利用リライト）。有効にすると、プランナー（RewriteMultiDistinctRule）はマルチカラム DISTINCT、スキューした集計、または統計により CTE リライトの方が効率的であると示される場合に CTE ベースのリライトを選択することがあり、prefer_cte_rewrite ヒントを尊重します。無効にすると CTE ベースのリライトは許可されず、プランナーは multi-function リライトを試みます。クエリが CTE を必要とする場合（例：マルチカラム DISTINCT や multi-function リライトで扱えない関数など）は、プランナーはユーザーエラーを発生させます。注意：オプティマイザが参照する実際の設定はこのフラグとパイプラインエンジンフラグの論理 AND です — すなわち isCboCteReuse() はこの変数と enablePipelineEngine の両方を返す必要があるため、enablePipelineEngine がオンのときのみ CTE 再利用が有効になります。
  • デフォルト: true
  • タイプ: Boolean
  • 導入バージョン: v3.2.0

cbo_disabled_rules​

  • 説明: 現在のセッションで無効にするオプティマイザルール名のカンマ区切りリスト。各名前は RuleType 列挙値に一致する必要があり、無効化できるのは名前が TF_（変換ルール）または GP_（グループ結合ルール）で始まるルールのみです。セッション変数は SessionVariable に格納され（getCboDisabledRules / setCboDisabledRules）、オプティマイザは OptimizerOptions.applyDisableRuleFromSessionVariable() を通じて適用します。同関数はリストを解析し、対応するルールスイッチをクリアしてプランニング時にそれらのルールをスキップします。SET ステートメントを通じて設定された場合、値は検証され、サーバは不明な名前や TF_/GP_ で始まらない名前を明確なエラーメッセージ（例: "Unknown rule name(s): ..." や "Only TF_ ... and GP_ ... can be disabled"）で拒否します。プランナ実行時には不明なルール名は警告とともに無視されます（"Ignoring unknown rule name: ... (may be from different version)" とログに残る）。名前は列挙子識別子と正確に一致する必要があります（大文字小文字を区別）。名前の前後の空白はトリムされ、空のエントリは無視されます。
  • スコープ: Session
  • デフォルト: "" (無効化されたルールなし)
  • データ型: String
  • 導入バージョン: -

cbo_enable_low_cardinality_optimize​

  • 説明: 低基数最適化を有効にするかどうか。この機能を有効にすると、STRING 列のクエリパフォーマンスが約 3 倍向上します。
  • デフォルト: true

cbo_eq_base_type​

  • 説明: DECIMAL データと STRING データの間でデータ比較に使用されるデータ型を指定します。デフォルト値は DECIMAL であり、VARCHAR も有効な値です。この変数は = および != 比較にのみ有効です。
  • データ型: 文字列
  • 導入バージョン: v2.5.14

cbo_json_v2_dict_opt​

  • 説明: JSON v2 のパス書き換えで生成される Flat JSON の文字列サブカラムに対して、低カーディナリティ辞書最適化を有効にするかどうか。有効にすると、オプティマイザはそれらのサブカラムにグローバル辞書を構築・利用し、文字列式、GROUP BY、JOIN などを高速化できます。
  • デフォルト: true
  • データ型: Boolean

cbo_json_v2_rewrite​

  • 説明: オプティマイザで JSON v2 のパス書き換えを有効にするかどうか。有効にすると、JSON 関数（get_json_* など）を Flat JSON のサブカラムへの直接アクセスに書き換え、述語プッシュダウン、カラムプルーニング、辞書最適化を有効化します。
  • デフォルト: true
  • データ型: Boolean

cbo_max_reorder_node_use_dp​

  • 説明: コストベースオプティマイザ（CBO）が DP（動的計画法）join-reorder アルゴリズムを含めるかを制御するセッションスコープの上限です。オプティマイザは join 入力数（MultiJoinNode.atoms.size()）をこの値と比較し、multiJoinNode.getAtoms().size() <= cbo_max_reorder_node_use_dp かつ cbo_enable_dp_join_reorder が有効な場合にのみ DP reorder を実行または追加します。JoinReorderFactory.createJoinReorderAdaptive（候補アルゴリズムに JoinReorderDP を追加するため）および ReorderJoinRule.transform/rewrite（メモにプランをコピーするときに JoinReorderDP を実行するか決定するため）で使用されます。デフォルト値の 10 は実用的な性能のカットオフを反映しています（コード内コメント: "10 table join reorder takes more than 100ms"）。この設定はオプティマイザの実行時間（DP は高コスト）と大規模な multi-join クエリに対するプラン品質のトレードオフを調整するためにチューニングしてください。cbo_enable_dp_join_reorder および 貪欲法の閾値 cbo_max_reorder_node_use_greedy と相互作用します。比較は包含比較（<=）です。
  • スコープ: セッション
  • デフォルト: 10
  • データタイプ: long
  • 導入バージョン: v3.2.0

cbo_max_reorder_node_use_exhaustive​

  • スコープ: セッション
  • 説明: CBO における join-reorder アルゴリズム選択の閾値を制御します。オプティマイザはクエリ内の inner/cross join ノードをカウントし、その数がこの値より大きい場合、プランナは transform ベースの（より積極的な）reorder パスを取ります：CTE 統計の収集を強制し、ReorderJoinRule.transform および関連する可換性ルールを呼び出します。カウントがこの値以下の場合、プランナはより安価な join-transformation ルールを適用します（特定の semi/anti-join ケースでは INNER_JOIN_LEFT_ASSCOM_RULE を追加することがあります）。このセッション変数はオプティマイザ（SPMOptimizer, QueryOptimizer）で参照され、セッションレベルでは setMaxTransformReorderJoins を介して設定できます。
  • デフォルト: 4
  • データタイプ: int
  • 導入バージョン: v3.2.0

cbo_max_reorder_node_use_greedy​

  • 説明: コストベースオプティマイザが greedy join-reorder アルゴリズムを検討するマルチジョイン内の結合入力（アトム）の最大数。オプティマイザは候補となるリオーダーアルゴリズムのリストを構築する際にこの制限（cbo_enable_greedy_join_reorder と併せて）をチェックします：もし multiJoinNode.getAtoms().size() がこの値以下であれば、JoinReorderGreedy のインスタンスが追加され実行されます。この変数は JoinReorderFactory.createJoinReorderAdaptive() と ReorderJoinRule によって、ジョインリオーダー段階での greedy リオーダリングの適用可否を制御するために使用されます。セッションごとに適用され、統計情報が利用可能でかつ greedy が有効な場合に greedy リオーダリングが試行されるかに影響します。多数の結合されたリレーションを含むクエリに対するオプティマイザの時間/複雑度のトレードオフを制御するために調整してください。
  • スコープ: Session (セッションごとに変更可能)
  • デフォルト: 16
  • データタイプ: long
  • 導入バージョン: v3.4.0, v3.5.0

cbo_use_correlated_predicate_estimate​

  • 説明: セッションフラグ。オプティマイザが、複数列にまたがる結合された等価述語の選択率を推定する際に相関を考慮したヒューリスティックを適用するかを制御します。有効（デフォルト）の場合、推定器はプライマリのマルチカラム統計や最も選択的な述語を除く追加列に対して指数減衰重みを適用し、追加述語の乗算的影響を軽減します（重み：追加最大3列に対して 0.5、0.25、0.125）。無効の場合、減衰は適用されず（減衰係数 = 1）、これらの列の完全な選択率を乗算します（より強い独立仮定）。このフラグは StatisticsEstimateUtils.estimateConjunctiveEqualitySelectivity により確認され、マルチカラム統計経路とフォールバック経路の両方で減衰係数を選択するため、CBO が使用するカーディナリティ推定に影響します。
  • スコープ: Session
  • デフォルト: true
  • タイプ: boolean
  • 導入バージョン: v3.5.0

changes_scan_cache_mode​

  • 説明: CHANGES クエリが読み取ったデータをコンピュートノードのキャッシュに書き込むかどうかを指定します。CHANGES クエリはテーブルの行レベルの変更をバージョン範囲にわたって返すため、テーブルの最新バージョンにはもう含まれていないデータも読み取ります。有効な値：
    • auto（デフォルト）：システムが判断します。現在は always と同じ動作です。
    • always：通常のクエリと同様にデータをキャッシュします。
    • never：データキャッシュを埋めずに読み取ります。大規模なバックフィルが通常のクエリの依存するデータをキャッシュから追い出すことを防ぎます。
  • スコープ: Session
  • デフォルト: auto
  • タイプ: 文字列
  • 導入バージョン: v26.2

character_set_database (global)​

  • データ型: 文字列 StarRocks がサポートする文字セット。UTF8 (utf8) のみがサポートされています。
  • デフォルト: utf8
  • データ型: 文字列

collation_server​

  • スコープ: Session
  • 説明: FE がこのセッションに対して MySQL 互換の照合順序動作を提示するために使用するセッションレベルのサーバ照合名。この変数は、FE がクライアントに報告し、character_set_server / collation_connection / collation_database に関連付けられるデフォルトの照合識別子（例: utf8_general_ci）を設定します。セッション変数 JSON に永続化されます（SessionVariable#getJsonString / replayFromJson を参照）および変数マネージャーを通じて公開されます（@VarAttr(name = COLLATION_SERVER)）、したがって SHOW VARIABLES に表示されセッションごとに変更可能です。値は SessionVariable にプレーンな String として保存され、通常は標準的な MySQL の照合名（例: utf8_general_ci, utf8mb4_unicode_ci）を保持します。ここでコードは固定列挙型を強制したり追加の検証を行ったりしないため、比較やソートなど照合に敏感な操作の実際の動作は照合名を解釈する下流コンポーネントに依存します。
  • デフォルト: utf8_general_ci
  • データ型: String
  • 導入バージョン: v3.2.0

computation_fragment_scheduling_policy​

  • スコープ: セッション
  • 説明: 計算フラグメントの実行インスタンスを選択するために使用されるスケジューラポリシーを制御します。有効な値（大文字小文字を区別しない）は次のとおりです:
    • compute_nodes_only — フラグメントを compute ノードのみにスケジュールします（デフォルト）。
    • all_nodes — compute ノードと従来のバックエンドノードの両方でのスケジューリングを許可します。 この変数は enum SessionVariableConstants.ComputationFragmentSchedulingPolicy によってバックされます。設定されると値は enum に対して検証（大文字化して比較）され、無効な値はエラーを引き起こします（API 経由で設定した場合は IllegalArgumentException、SET 文で使用した場合は SemanticException）。ゲッターは対応する enum 値を返し、未設定または認識できない場合は COMPUTE_NODES_ONLY にフォールバックします。この設定はプラン作成／デプロイ時に FE がフラグメント配置先ノードを選択する方法に影響します。
  • デフォルト: COMPUTE_NODES_ONLY
  • タイプ: String
  • 導入バージョン: v3.2.7

connector_io_tasks_per_scan_operator​

  • 説明: 外部テーブルクエリ中にスキャンオペレーターによって発行される最大同時 I/O タスク数。値は整数です。現在、StarRocks は外部テーブルをクエリする際に同時 I/O タスクの数を適応的に調整できます。この機能は、デフォルトで有効になっている変数 enable_connector_adaptive_io_tasks によって制御されます。
  • デフォルト: 16
  • データ型: Int
  • 導入バージョン: v2.5

connector_sink_compression_codec​

  • 説明: Hive テーブルまたは Iceberg テーブルにデータを書き込む際、または Files() でデータをエクスポートする際に使用される圧縮アルゴリズムを指定します。このパラメータは、以下の状況でのみ有効になります：
    • Hive テーブルに compression_codec プロパティが存在しない場合。
    • Iceberg テーブルに write.parquet.compression-codec プロパティが存在しない場合。
    • INSERT INTO FILES に対して compression プロパティが設定されていない場合。
  • 有効な値: uncompressed, snappy, lz4, zstd, および gzip。
  • デフォルト: uncompressed
  • データ型: 文字列
  • 導入バージョン: v3.2.3

connector_sink_target_max_file_size​

  • 説明: Hive テーブルまたは Iceberg テーブルにデータを書き込む際、または Files() でデータをエクスポートする際のターゲットファイルの最大サイズを指定します。この制限は厳密ではなく、ベストエフォートで適用されます。
  • 単位: バイト
  • デフォルト: 1073741824
  • データ型: Long
  • 導入バージョン: v3.3.0

count_distinct_column_buckets​

  • 説明: グループバイカウントディスティンクトクエリでの COUNT DISTINCT 列のバケット数。この変数は enable_distinct_column_bucketization が true に設定されている場合にのみ有効です。
  • デフォルト: 1024
  • 導入バージョン: v2.5

count_distinct_implementation​

  • 説明: COUNT(DISTINCT expr) にパラメータが 1 つだけ含まれる場合の関数実装を制御します。使用できる値（大文字と小文字は区別されません）:
    • default: COUNT(DISTINCT expr) の実装をデフォルトのままにします。オプティマイザは、クエリ形式、統計情報、およびコストに基づいて適切な集計プランを選択します。
    • multi_count_distinct: COUNT(DISTINCT expr) の実装を multi_distinct_count に変更し、正確なカウントを行います。カーディナリティが低い列または中程度の列をカウントする場合、この実装によってシャッフルおよび重複排除のフェーズを 1 つ削減でき、クエリの速度を向上させられる場合があります。ただし、distinct 値を HashSet に保持するため、カーディナリティが高い列を重複排除するとメモリ使用量が過剰になり、OOM が発生する可能性があります。代表的なワークロードで事前に検証せず、この値をグローバルに設定しないでください。
    • ndv: COUNT(DISTINCT expr) の実装を ndv(expr) に変更します。この関数は HyperLogLog を使用するため、メモリ使用量を抑えながら近似結果を返します。
  • デフォルト: default
  • 導入バージョン: v3.3.6、v3.4.0
multi_distinct_count の使用上の注意事項

multi_distinct_count() は正確な結果を返します。

ほとんどのクエリでは、COUNT(DISTINCT expr) の使用を推奨します。オプティマイザが適切な集計プランを選択できるように、count_distinct_implementation を default に設定してください。

カーディナリティが低い列または中程度の列を重複排除する場合は、multi_distinct_count() をテストして使用できます。この関数は 2 フェーズの集計を使用するため、シャッフルおよび重複排除のフェーズを 1 つ削減し、パフォーマンスを向上させられる場合があります。ただし、HashSet の状態保持と最終マージによってメモリ使用量が過剰になり、カーディナリティが高い列を重複排除すると OOM が発生する可能性があります。

セッション全体ではなく、特定の COUNT(DISTINCT expr) に対してこの実装をテストする場合は、クエリヒントで count_distinct_implementation を設定できます。

SELECT /*+ SET_VAR(count_distinct_implementation = multi_count_distinct) */
       COUNT(DISTINCT category)
FROM test;

この値をヒントで設定した場合、適用対象はパラメータが 1 つの COUNT(DISTINCT) のみに限定されます。COUNT(DISTINCT expr1, expr2) のような複数列の重複排除式には影響しません。

custom_query_id (session)​

  • 説明: 現在のクエリに外部識別子をバインドするために使用されます。クエリ実行前に SET SESSION custom_query_id = 'my-query-id'; のように設定できます。クエリ終了後に値はリセットされます。この値は KILL QUERY 'my-query-id' に渡すことができます。値は監査ログの customQueryId フィールドで確認できます。
  • デフォルト: ""
  • データタイプ: String
  • 導入バージョン: v3.4.0

datacache_sharing_work_period​

  • 説明: キャッシュ共有が有効になる期間。各クラスタースケーリング操作の後、キャッシュ共有機能が有効になっている場合、この期間内のリクエストのみが他のノードからキャッシュデータにアクセスしようとします。
  • デフォルト: 600
  • 単位: Seconds
  • 導入バージョン: v3.5.1

default_authentication_plugin​

  • スコープ: Session
  • 説明: このセッションのデフォルトの MySQL 認証プラグイン名を指定するセッションスコープの変数です。SessionVariable.defaultAuthenticationPlugin として格納され、サーバーがデフォルトの認証プラグインを告知または使用する必要がある場合（ハンドシェイク時やプラグインが指定されていない場合など）に、StarRocks の MySQL プロトコル互換レイヤーで使用されます。サーバーがサポートする標準的な MySQL 認証プラグイン識別子（例: mysql_native_password, caching_sha2_password）を受け付けます。この変数はセッション動作にのみ影響し、永続的なユーザーアカウントの認証構成は別途管理されます。関連するセッション変数 authentication_policy を参照してください。
  • デフォルト: mysql_native_password
  • データタイプ: String
  • 導入バージョン: -

default_rowset_type (global)​

コンピューティングノードのストレージエンジンで使用されるデフォルトのストレージ形式を設定するために使用されます。現在サポートされているストレージ形式は alpha と beta です。

default_table_compression​

  • 説明: テーブルストレージのデフォルト圧縮アルゴリズム。サポートされている圧縮アルゴリズムは snappy, lz4, zlib, zstd です。

    CREATE TABLE 文で compression プロパティを指定した場合、compression で指定された圧縮アルゴリズムが有効になります。

  • デフォルト: lz4_frame

  • 導入バージョン: v3.0

default_tmp_storage_engine​

  • 説明: セッション変数で、テンポラリテーブル（明示的な CREATE TEMPORARY TABLE およびエンジンによって作成される内部/暗黙のテンポラリテーブル）のデフォルトのストレージエンジンを制御します。SessionVariable.java に @VariableMgr.VarAttr アノテーションで宣言されており、主に MySQL 8.0 互換性のために存在し、MySQL ライクな動作を期待するクライアントやツールがセッションごとに一時テーブルのエンジンを確認または変更できるようにします。この値を変更すると、メモリバックエンドとディスクバックエンドなど、異なるエンジンを尊重するストレージ層でのテンポラリテーブルデータの保存/管理方法に影響します。
  • スコープ: Session
  • デフォルト: InnoDB
  • データタイプ: String
  • 導入バージョン: v3.4.2, v3.5.0

default_view_sql_security​

  • 説明: CREATE VIEW ステートメントで SECURITY 句が指定されていない場合に適用される、デフォルトの SQL SECURITY 特性です。NONE（明示的な SECURITY NONE 句と同等）はビューを参照する際に実行ユーザーがそのビュー自体に対する SELECT 権限を持っていればよく、ビューが参照するテーブルは実行ユーザーに対してチェックされないことを意味します。INVOKER（SECURITY INVOKER と同等）は実行ユーザーがビューの参照するテーブルに対する SELECT 権限も持っている必要があることを意味します。ステートメント内で明示的に指定された SECURITY NONE または SECURITY INVOKER 句は、常にこの変数より優先されます。この変数は CREATE VIEW にのみ影響し、ALTER VIEW には影響しません。
  • スコープ: Session
  • デフォルト: NONE
  • データタイプ: String
  • 有効な値: NONE, INVOKER
  • 導入バージョン: v4.1.1

disable_colocate_join​

  • 説明: Colocation Join を有効にするかどうかを制御するために使用されます。デフォルト値は false で、機能が有効です。この機能が無効になっている場合、クエリプランニングは Colocation Join を実行しようとしません。
  • デフォルト: false

disable_join_reorder​

  • スコープ: Session
  • 説明: コストベースオプティマイザが結合の並べ替え（join reordering）を行うかどうかを制御します。false（デフォルト）では、オプティマイザは新しいプランナ経路（SPMOptimizer や QueryOptimizer に見られる）における論理最適化中に結合並べ替え変換（例：ReorderJoinRule、join transformation や outer-join transformation ルール）を適用する場合があります。true の場合、結合の並べ替えおよび関連する outer-join reorder ルールはスキップされ、オプティマイザが結合順序を変更することを防ぎます。これは最適化時間を短縮したり、安定／再現可能な結合順序を得たり、CBO の並べ替えが非最適なプランを生成するケースを回避するのに有用です。この設定は cbo_max_reorder_node、cbo_max_reorder_node_use_exhaustive、enable_outer_join_reorder のような他の CBO／セッション制御と相互作用します。
  • デフォルト: false
  • データタイプ: boolean
  • 導入バージョン: v3.2.0

disable_spill_to_local_disk​

  • 説明: セッションで true に設定すると、FE は BE に対してローカルディスクへのスピルを無効にし、代わりにリモートストレージへのスピルに依存するよう指示します（リモートスピルが構成されている場合）。このフラグは enable_spill = true、enable_spill_to_remote_storage = true、かつ有効な spill_storage_volume が FE によって検出されている場合にのみ意味を持ちます。値は TSpillToRemoteStorageOptions（BE に送信）に disable_spill_to_local_disk としてシリアライズされます。リモートスピルが構成されていないか、指定されたストレージボリュームが解決できない場合、この設定は効果を持ちません。注意して使用してください：ローカルディスクへのスピルを無効化するとネットワーク I/O とレイテンシが増加し、信頼性・高性能なリモートストレージを必要とします。
  • スコープ: Session
  • デフォルト: false
  • データ型: boolean
  • 導入バージョン: v3.3.0, v3.4.0, v3.5.0

div_precision_increment​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

dynamic_overwrite​

  • 説明: パーティションテーブルを使用した INSERT OVERWRITE の Dynamic Overwrite セマンティクスを有効にするかどうか。有効な値:
    • true: Dynamic Overwrite を有効にします。
    • false: Dynamic Overwrite を無効にし、デフォルトのセマンティクスを使用します。
  • デフォルト: false
  • 導入バージョン: v3.4.0

enable_adaptive_sink_dop​

  • 説明: データロードの適応並行性を有効にするかどうかを指定します。この機能を有効にすると、システムは INSERT INTO および Broker Load ジョブのロード並行性を自動的に設定し、pipeline_dop のメカニズムと同等になります。新しくデプロイされた v2.5 StarRocks クラスタでは、デフォルトで true に設定されています。v2.4 からアップグレードされた v2.5 クラスタでは、デフォルトで false に設定されています。
  • デフォルト: false
  • 導入バージョン: v2.5

enable_bucket_aware_execution_on_lake​

  • 説明: データレイク（例：Iceberg テーブル）に対するクエリにおいて、Bucket-aware 実行を有効にするかどうか。この機能を有効にすると、システムはバケット情報を活用してデータシャッフルを削減し、パフォーマンスを向上させることでクエリの実行を最適化します。この最適化は、バケット化されたテーブルにおける Join 操作や集計処理において特に効果的です。
  • デフォルト: true
  • タイプ: Boolean
  • 導入バージョン: v4.0

enable_cbo_based_mv_rewrite​

  • 説明: CBO フェーズでマテリアライズドビューの書き換えを有効にするかどうか。これにより、クエリ書き換えの成功率を最大化できます（例：マテリアライズドビューとクエリの結合順序が異なる場合）が、オプティマイザフェーズの実行時間が増加します。
  • デフォルト: true
  • 導入バージョン: v3.5.5, v4.0.1

enable_cbo_table_prune​

  • 説明: 有効にすると、オプティマイザはメモ最適化中に CBO テーブルプルーニングルール（CboTablePruneRule）を追加して、カーディナリティを保持する結合に対するコストベースのテーブルプルーニングを行います。ルールはオプティマイザ内で条件付きに追加されます（QueryOptimizer.memoOptimize および SPMOptimizer.memoOptimize を参照）— 結合ツリー内の結合ノード数が小さい場合（10 未満の結合ノード）にのみ追加されます。このオプションはルールベースのプルーニング切替 enable_rbo_table_prune を補完し、Cost-Based Optimizer が結合処理から不要なテーブルや入力を取り除いてプランと実行の複雑さを軽減できるようにします。プルーニングはプラン形状を変更する可能性があるためデフォルトはオフです。代表的なワークロードで検証してから有効化してください。
  • スコープ: Session
  • デフォルト: false
  • タイプ: boolean
  • 導入バージョン: v3.2.0

enable_color_explain_output​

  • スコープ: Session
  • 説明: テキスト形式の EXPLAIN / PROFILE 出力に ANSI カラーエスケープシーケンスを含めるかどうかを制御します。有効（true）のとき、StmtExecutor はセッション設定を explain/profile パイプライン（ExplainAnalyzer への呼び出しを通じて）に渡すため、explain、EXPLAIN ANALYZE、analyze-profile 出力に ANSI 対応端末での可読性を高めるカラー強調表示が含まれます。無効（false）のときは ANSI シーケンスなし（プレーンテキスト）で出力され、ログや ANSI をサポートしないクライアント、または出力をファイルにパイプする場合に適しています。これはセッション単位のトグルであり、実行のセマンティクスを変更するものではなく、explain/profile テキストの表示方法のみを変更します。
  • デフォルト: true
  • データタイプ: boolean
  • 導入バージョン: v3.5.0

enable_connector_adaptive_io_tasks​

  • 説明: 外部テーブルをクエリする際に同時 I/O タスクの数を適応的に調整するかどうか。デフォルト値は true です。この機能が有効でない場合、変数 connector_io_tasks_per_scan_operator を使用して同時 I/O タスクの数を手動で設定できます。
  • デフォルト: true
  • 導入バージョン: v2.5

enable_datacache_async_populate_mode​

  • 説明: データキャッシュを非同期モードでポピュレートするかどうか。デフォルトでは、システムは同期モードを使用してデータキャッシュをポピュレートします。つまり、データをクエリしながらキャッシュをポピュレートします。
  • デフォルト: false
  • 導入バージョン: v3.2.7

enable_datacache_io_adaptor​

  • 説明: Data Cache I/O アダプタを有効にするかどうか。この機能を有効にすると、ディスク I/O 負荷が高い場合にシステムが一部のキャッシュ要求をリモートストレージに自動的にルーティングし、ディスクの負荷を軽減します。
  • デフォルト: true
  • 導入バージョン: v3.3.0

enable_datacache_sharing​

  • 説明: キャッシュ共有を有効にするかどうか。これを true に設定すると、この機能が有効になります。キャッシュ共有は、ネットワークを介して他のノードからキャッシュデータにアクセスすることをサポートするために使用されます。これは、クラスタのスケーリング中にキャッシュが無効になることによって発生するパフォーマンスのジッタを軽減するのに役立ちます。この変数は FE パラメータ enable_trace_historical_node が true に設定されている場合にのみ有効になります。
  • デフォルト: true
  • 導入バージョン: v3.5.1

enable_distinct_agg_over_window​

  • 説明: WINDOW句上の DISTINCT 集約呼び出しを等価な join ベースのプランに変換するオプティマイザのリライトを制御します。有効（true、デフォルト）の場合、QueryOptimizer.invoke convertDistinctAggOverWindowToNullSafeEqualJoin は以下を行います:
    • LogicalWindowOperator を含むクエリを検出、
    • project-merge リライトを実行し、論理プロパティを導出、
    • DistinctAggregationOverWindowRule を適用して DISTINCT-OVER-WINDOW パターンを null-safe equality join に変換（プラン形状を変更してさらに push-down や集約最適化を有効にする）、
    • その後 SeparateProjectRule を実行してプロパティを再導出。 無効（false）の場合、オプティマイザはこの変換をスキップし、ウィンドウ上の DISTINCT 集約を変更せずに残します。この設定はセッションスコープで、オプティマイザのリライトフェーズ（QueryOptimizer.convertDistinctAggOverWindowToNullSafeEqualJoin を参照）にのみ影響します。
  • デフォルト: true
  • データタイプ: boolean
  • 導入バージョン: -

enable_distinct_column_bucketization​

  • 説明: グループバイカウントディスティンクトクエリで COUNT DISTINCT 列のバケット化を有効にするかどうか。クエリ select a, count(distinct b) from t group by a; を例にとります。GROUP BY 列 a が低基数列で、COUNT DISTINCT 列 b が高基数列でデータスキューが激しい場合、パフォーマンスボトルネックが発生します。この状況では、COUNT DISTINCT 列のデータを複数のバケットに分割してデータをバランスさせ、データスキューを防ぐことができます。この変数は、変数 count_distinct_column_buckets と一緒に使用する必要があります。

    クエリに skew ヒントを追加することで、COUNT DISTINCT 列のバケット化を有効にすることもできます。例：select a,count(distinct [skew] b) from t group by a;。

  • デフォルト: false、つまりこの機能は無効です。

  • 導入バージョン: v2.5

enable_force_rule_based_mv_rewrite​

  • 説明: オプティマイザのルールベース最適化フェーズで複数テーブルに対するクエリの書き換えを有効にするかどうか。この機能を有効にすると、クエリ書き換えの堅牢性が向上します。ただし、クエリがマテリアライズドビューを見逃した場合、時間消費が増加します。
  • デフォルト: true
  • 導入バージョン: v3.3.0

enable_gin_filter​

enable_global_runtime_filter​

グローバルランタイムフィルタ（RF の略）を有効にするかどうか。RF は実行時にデータをフィルタリングします。データフィルタリングは通常、ジョイン段階で発生します。複数テーブルのジョイン中に、述語プッシュダウンなどの最適化を使用してデータをフィルタリングし、ジョインのスキャン行数とシャッフル段階の I/O を削減し、クエリを高速化します。

StarRocks は 2 種類の RF を提供します：ローカル RF とグローバル RF。ローカル RF は Broadcast Hash Join に適しており、グローバル RF は Shuffle Join に適しています。

デフォルト値: true、つまりグローバル RF が有効です。この機能が無効になっている場合、グローバル RF は効果を発揮しません。ローカル RF は引き続き機能します。

enable_group_by_compressed_key​

  • 説明: GROUP BY キー列を圧縮するために正確な統計情報を使用するかどうか。有効な値: true と false。
  • デフォルト: true
  • 導入バージョン: v4.0

enable_group_execution​

  • 説明: Colocate Group Executionを有効化するかどうか。Colocate Group Executionは物理的なデータ分割を活用する実行パターンであり、固定数のスレッドがそれぞれのデータ範囲を順次処理することで局所性とスループットを向上させます。この機能を有効化するとメモリ使用量を削減できます。
  • デフォルト: true
  • 導入バージョン: v3.3

enable_group_level_query_queue (global)​

  • 説明: リソースグループレベルのクエリキューを有効にするかどうか。
  • デフォルト: false、つまりこの機能は無効です。
  • 導入バージョン: v3.1.4

enable_incremental_mv​

  • 説明: セッションフラグで、サーバーが増分リフレッシュを使用するマテリアライズドビューに対してプランを生成し、インメモリのプランを保持するかを制御します。有効にすると、MaterializedViewAnalyzer.planMVQuery はリフレッシュスキームが IncrementalRefreshSchemeDesc である create-MV ステートメントに対して処理を行います：ビュークエリの論理・物理プランを構築し、セッションの enableMVPlanner フラグを設定します（setMVPlanner(true)）。無効にすると、増分リフレッシュ MV のプラン作成はスキップされます。SessionVariable の isEnableIncrementalRefreshMV() および setEnableIncrementalRefreshMv(boolean) からアクセス可能です。
  • スコープ: セッション（接続ごと）
  • デフォルト: false
  • データ型: boolean
  • 導入バージョン: v3.2.0

enable_insert_partial_update​

  • 説明：主キーテーブルに対するINSERTステートメントの部分更新を有効化するかどうか。この項目が true（デフォルト）に設定されている場合、INSERT ステートメントで指定された列がサブセット（テーブル内のすべての非生成列の数より少ない）であるとき、システムは部分更新を実行し、指定された列のみを更新しながら他の列の既存値を保持します。false に設定すると、システムは既存の値を保持する代わりに、指定されていない列に対してデフォルト値を使用します。この機能は、主キーテーブルの特定の列を更新する際に他の列の値に影響を与えない場合に特に有用です。
  • デフォルト値：true
  • 導入バージョン：v3.3.20、v3.4.9、v3.5.8、v4.0.2

enable_insert_strict​

  • 説明: Files() からの INSERT を使用してデータをロードする際に厳密モードを有効にするかどうか。有効な値: true および false（デフォルト）。厳密モードが有効な場合、システムは資格のある行のみをロードします。不適格な行をフィルタリングし、不適格な行の詳細を返します。詳細は Strict mode を参照してください。v3.4.0 より前のバージョンでは、enable_insert_strict が true に設定されている場合、不適格な行があると INSERT ジョブが失敗します。
  • デフォルト: true

max_unknown_string_meta_length (global)​

  • 説明: 文字列列の最大長が不明な場合にメタデータで使用するフォールバック長。メタデータの長さが実際より小さいと、一部の BI ツールで空値や切り詰めが発生する可能性があります。0 以下は 64 にフォールバックします。有効範囲は 1 ～ 1048576。
  • デフォルト: 64
  • データ型: Int
  • 導入バージョン: v3.5.16, v4.0.9

enable_reduce_cast_varchar_length_inheritance (global)​

  • 説明: ReduceCastRule が同一型の VARCHAR -> VARCHAR cast を削除する際に、ターゲットの VARCHAR(N) 長を保持するかどうかを制御します。これを有効にすると、CAST(col AS VARCHAR(N)) のような文で prepare と execute の結果セットメタデータを一致させることができます。
  • デフォルト: false
  • データ型: Boolean
  • 導入バージョン: v3.5.16, v4.0.9

enable_reduce_cast_varchar_expr_sync_type (global)​

  • 説明: ReduceCastRule が同一型の VARCHAR -> VARCHAR cast を削除した後、再利用される planner Expr の type と originType を書き換え後の VARCHAR(N) に同期するかどうかを制御します。
  • デフォルト: true
  • データ型: Boolean
  • 導入バージョン: v3.5.16, v4.0.9

enable_jdbc_array_lower_bound_correction​

  • 説明: PostgreSQL JDBC Catalog にプッシュダウンされる定数の配列添字を、各配列値が持つ下限に合わせて補正するかどうかを指定します。PostgreSQL の配列の下限は値ごとに保持される属性であり、読み取り時には保持されません。ドライバーは通常の配列を返し、StarRocks はそれを位置 1 起点に振り直します。この変数が false（デフォルト）の場合、添字は a[k] のままプッシュダウンされ、下限が 1 であると仮定します。PostgreSQL 自身が構築する配列の下限は 1 なのでこの仮定は成り立ちますが、別の下限で格納された値では、プッシュダウンされた添字は StarRocks でローカルに評価した同じ添字とは異なる要素を返します。エラーも警告もありません。[0:2]={zero,one,two} として格納された値では、リモートの items[1] は one を返しますが StarRocks は zero を返します。[5:7]={a,b,c} ではリモートは NULL を返しますが StarRocks は a を返します。PostgreSQL のテーブルに下限が 1 以外の配列が含まれており、プッシュダウンの結果を StarRocks の結果と完全に一致させる必要がある場合は、この変数を true に設定してください。その場合、添字は行ごとに array_lower() を用いて補正され、array_length() によるガードが付きます。この変数が制御するのは送信される SQL だけです。プッシュダウンされる式の範囲はどちらの値でも同じなので、この変数を切り替えてもクエリが配列カラム全体を読み戻すかどうかは変わりません。
  • デフォルト: false
  • データ型: Boolean

enable_jdbc_array_subscript_push_down​

  • 説明: PostgreSQL JDBC Catalog のカラムに対する定数の配列添字（items[1]、および等価な element_at(items, 1)）を、配列カラム全体を読み戻して StarRocks で添字を取るのではなく、PostgreSQL に評価させるかどうかを指定します。有効な値は true（デフォルト）と false です。この変数を false に設定すると、このプッシュダウンをロールバックできます。その場合、添字はどちらの経路でもプッシュダウンされません。WHERE 句の添字は述語ごと StarRocks に残り、SELECT リストの添字もリモートクエリに畳み込まれません。配列カラム全体が読み戻され、添字はローカルで評価されます。これはこのプッシュダウンが導入される前の動作と同じです。無効にした場合の影響が 2 つあります。1 つ目は、enable_jdbc_array_lower_bound_correction が完全に効かなくなることです。この変数はプッシュダウンされた添字の 2 つの表現を選ぶものであり、プッシュダウンされる添字が存在しないためです。したがって「ローカル評価とまったく同じ結果」を得る方法は 2 つあります。この変数を false にするか、true のままにして enable_jdbc_array_lower_bound_correction を true に設定する（プッシュダウンは維持されます）かです。2 つ目は、多次元の値を保持するカラムが再び直接読み取られるため、そのカラムに対するクエリは PostgreSQL から NULL を受け取るのではなく、未対応エラーになることです。

enable_jdbc_column_statistics​

  • 説明: JDBC Catalog が、データソース自身のシステムテーブルから読み取った列統計情報（列の異なる値の数、NULL の割合、平均列幅）をオプティマイザに渡すかどうかを指定します。有効な値は true（デフォルト）と false です。影響を受けるのはデータソースが実際に記述している列のみです。データソースが記述しなかった列は不明のままとなり、列統計情報をまったく報告しない方言（MySQL と ClickHouse は行数のみを報告します）は、従来どおり型に基づく比率推定を使い続けます。false に設定すると、すべての列がその推定に戻り、本機能の導入前の JDBC Catalog と同じ状態になります。この変数はテーブルの行数には影響しません。
  • デフォルト: true
  • データ型: Boolean

enable_jdbc_runtime_filter_push_down​

  • 説明: Join が構築したランタイムフィルタを、Build 側が生成した値の集合そのままの IN として、パラメータとしてバインドするのではなく SQL リテラルとして文に埋め込む形で JDBC Catalog スキャンのリモート SQL にプッシュダウンし、リモートのデータベースが一致しうる行だけを返すようにするかどうかを指定します。有効な値は true と false です。スキャンに届くのはローカル RF だけであるため、Join は JDBC テーブルを Probe 側に置いた Broadcast Hash Join である必要があります。Shuffle Join が構築するのはグローバル RF であり、プッシュダウンされません。Build 側の行数が max_pushdown_conditions_per_column（be.conf のデフォルトは 1024）を超える場合は、ランタイムフィルタ自体が構築されません。すべての方言でサポートされる Join キーの型は TINYINT、SMALLINT、INT、BIGINT、およびリモートの元の型がテキスト型であると確認できる文字列カラムです（PostgreSQL では VARCHAR カラムにその確認は不要です）。さらに PostgreSQL に限り、FLOAT と DATE のカラム、およびリモートの元の型がそれぞれ double precision（float8）と timestamp without time zone であると確認できる DOUBLE と DATETIME のカラムもサポートされます。timestamp with time zone のカラムは決してプッシュダウンされません。StarRocks はそれをクエリのタイムゾーンにおける壁時計時刻として読み取るため、夏時間の巻き戻しで重複する 1 時間内の異なる 2 つの時刻が同じ壁時計時刻に潰れ、リモートの IN が返す行が同じにならずに少なくなってしまうからです。同じ理由で、集約・射影・Join のプッシュダウンが生成する派生テーブルではリモートの元の型が分からないため、DOUBLE と DATETIME のフィルタはローカルに残ります（FLOAT と DATE はそこでもプッシュダウンされます）。それ以外のキーではフィルタはローカルで実行されます。TIME、CHAR、DECIMAL、JSON、および精度を指定せずに宣言された PostgreSQL の numeric を StarRocks が DECIMAL(38,18) にマッピングしたカラムも、これに含まれます。基本多言語面 (BMP) の外側の文字を値に含む文字列カラムでも、フィルタはローカルに残ります。完成した文を JDBC bridge へ渡す部分は modified UTF-8 としてデコードされ、そのような文字はそこでは 6 バイトのサロゲートペアであるため、4 バイトの UTF-8 形式は途中で切り詰められて届き、一致する行が変わるだけでなく、リテラルの途中で文が終わってしまうこともあるからです。これは絵文字に限らず、人名の稀用字を含む CJK 拡張 B も該当します。値にバックスラッシュを含む文字列カラムでも、フィルタはローカルに残ります。値自身のシングルクォートは重ねることでエスケープしますが、それが正しいのはリモートがバックスラッシュを通常の文字として読む間だけであり、PostgreSQL の standard_conforming_strings と MySQL の NO_BACKSLASH_ESCAPES は BE からは見えないセッション設定だからです。スキャン自体が行数制限を持つ場合は、リモートでのフィルタリングは行われません。リモートの文は行数制限より先に WHERE を適用する一方、ローカルの計画は行数制限の後にフィルタを適用するため、プッシュダウンすると返る行数が減るのではなく、返る行そのものが変わってしまいます。これはパフォーマンス上の選択ではなく、正しさのための要件です。クエリの実際の動作を確認するには、FE がそのスキャンを許可したかどうかを示す EXPLAIN VERBOSE 出力の RUNTIME FILTER PUSH DOWN 行と、BE がリモートの文に実際に書き込んだ内容およびフィルタが破棄された理由を示す Query Profile の PushdownRuntimeFilters および PushdownRuntimeFilterSkipped を併せて確認してください。
  • デフォルト: true
  • データ型: Boolean

enable_jdbc_topn_push_down​

  • 説明: 条件を満たす ORDER BY ... LIMIT 操作を PostgreSQL JDBC Catalog にプッシュダウンするかどうかを指定します。RESOURCE を使用して作成した従来の JDBC 外部テーブルでは、TopN は StarRocks 内で実行されます。有効な値は true と false です。TINYINT、SMALLINT、INT、BIGINT のソートキー（プッシュダウンされた集計の対応する型の結果を含む）をサポートします。さらに、元の型が確認できる場合は、次の PostgreSQL カラム型もサポートします: date および timestamp without time zone、boolean、text および varchar、精度が 38 以下で宣言された numeric/decimal。日付・時刻の範囲は西暦 0001 年から 9999 年までです。プッシュダウンされた式や集計の日付・時刻の結果はサポートされません。text と varchar のソートキーは、StarRocks のバイト順に合わせるためリモートで COLLATE "C" を使用してソートされます。そのため、別の collation で作成されたインデックスを PostgreSQL が使用できなくなる場合があります。リモートの ORDER BY はローカル TopN の入力ではなくその代わりとなり、スキャンは読み取った行の順序を保持します。OFFSET、既存のスキャン行数制限、またはローカルで実行する必要があるフィルターや集計を含むクエリはプッシュダウンされません。浮動小数点数、char/bpchar、enum、timestamp with time zone、および精度が 38 を超える numeric のソートキーはサポートされません。FE、すべての BE/CN ノード、およびその JDBC Bridge を同時にアップグレードしてください。本機能より古い BE/CN は読み取った行を並べ替えますが、順序を復元するためのローカル TopN はもう存在しません。日付・時刻のソートにはさらに、Bridge の PostgreSQL 日付・時刻を損失なく読み取る実装が必要です。
  • デフォルト: true
  • データ型: Boolean

enable_lake_prepared_physical_split_scan​

  • 説明: 共有データクラスタ内のクラウドネイティブ（レイク）テーブルに対して Prepared Physical Split Scan を有効にするかどうか。有効にすると、各セグメントは一度だけプルーニングされ、その Prepared Read State が同一タブレットの Split 子タスク間で共有されるため、大きい、またはデータが偏ったタブレットのスキャンを高速化できます。この最適化はスキャンノードごとに判断され、さらにクラウドネイティブテーブルであることと Query Cache が無効であることを必要とします。共有データクラスタでのみ有効です。
  • デフォルト: false
  • データ型: Boolean
  • 導入バージョン: v4.2

lake_tablet_internal_parallel_skew_split_ratio​

  • 説明: Prepared Physical Split scan において、Scan Range 数がすでに Pipeline DOP に達している場合でも、単一の巨大な Lake タブレットを分割できるようにするデータ偏りのしきい値。あるタブレットの行数が、この比率に Driver あたりの理想的な分担（総行数を有効 DOP で割った値）を掛けた値を超えると、そのタブレットは偏ったストラグラーとみなされて分割されます。値が大きいほど分割にはより極端な偏りが必要になり、値が小さいほど積極的に分割します。正の有限な数値である必要があります。enable_lake_prepared_physical_split_scan が有効なスキャンにのみ影響し、共有データクラスタでのみ有効です。
  • デフォルト: 1.5
  • データ型: Double
  • 導入バージョン: v4.2

enable_lake_prepared_split_on_dup_table_scan​

  • 説明: 同一クエリ内で 2 つ以上の Scan オペレータによってスキャンされるクラウドネイティブ（レイク）テーブル（セルフジョインや、複数回参照されるテーブルなど）に対して、Prepared Physical Split Scan を許可するかどうか。false（デフォルト）の場合、そのような重複スキャンは通常のスキャンにフォールバックします。この最適化が Scan ごとに再利用する Prepared Read State を、同一テーブルの兄弟 Scan 間で共有することは安全ではないためです。true に設定すると、それらのスキャンを最適化に再度組み込みます。enable_lake_prepared_physical_split_scan が有効なスキャンにのみ影響し、共有データクラスタでのみ有効です。
  • デフォルト: false
  • データ型: Boolean
  • 導入バージョン: v4.2

enable_lake_tablet_internal_parallel​

  • 説明: 共有データクラスタ内のクラウドネイティブテーブルに対する並列スキャンを有効にするかどうか。
  • デフォルト: true
  • データ型: Boolean
  • 導入バージョン: v3.3.0

enable_global_late_materialization​

  • 説明: Global Late Materialization（GLM）を制御します。GLM は、一般的なクエリオプティマイザの書き換えです。行数を制限するオペレータ（LIMIT を指定した TopN（たとえば、ORDER BY ... LIMIT）、または JOIN の上に配置された LIMIT）を含むプランの場合、GLM は述語、ソート、または結合キーに必要でない列のマテリアライズを遅延させ、LIMIT を通過した実際の行に対してのみ、行 ID ルックアップによって後から遅延させた列を取得します。これにより、LIMIT によって破棄される行の完全な列データを読み取ったり転送したりすることを回避できます。非集約キー（Duplicate、Unique、または Primary Key）テーブルのネイティブ OLAP テーブルおよび Iceberg テーブルに適用されます。
  • デフォルト: true
  • データ型: Boolean
  • 導入バージョン: v26.2

enable_load_profile​

  • スコープ: Session
  • 説明: 有効にすると、FE はロードジョブのランタイムプロファイルの収集を要求し、ロード完了後にロードコーディネータがプロファイルを収集/エクスポートします。ストリームロードの場合、FE は TQueryOptions.enable_profile = true を設定し、stream_load_profile_collect_threshold_second からの load_profile_collect_second をバックエンドに渡します。コーディネータは条件に応じてプロファイル収集を呼び出します（StreamLoadTask.collectProfile() を参照）。実際の振る舞いは、このセッション変数と宛先テーブルのテーブルレベルプロパティ enable_load_profile の論理 OR です。収集はさらに load_profile_collect_interval_second（FE 側のサンプリング間隔）によって制御され、頻繁な収集を回避します。セッションフラグは SessionVariable.isEnableLoadProfile() を介して読み取られ、setEnableLoadProfile(...) で接続ごとに設定できます。
  • デフォルト: false
  • データ型: boolean
  • 導入バージョン: v3.2.0

enable_local_shuffle_agg​

  • 説明: プランナーとコストモデルが、二相／グローバルシャッフル集約の代わりにローカルシャッフルを用いた単一フェーズのローカル集約プラン（Scan -> LocalShuffle -> OnePhaseAgg）を生成することを許可するかを制御します。有効（デフォルト）の場合、オプティマイザとコストモデルは次を行います：
    • Scan と Global Agg の間の SHUFFLE 交換を、単一バックエンド兼コンピュートノードのクラスタでローカルシャッフル + ワンフェーズ集約に置き換えることを許可する（PruneShuffleDistributionNodeRule と EnforceAndCostTask を参照）、
    • その単一ノードのケースでネットワークコストを無視してワンフェーズプランを優先させる（CostModel）。 置換は enable_pipeline_engine が有効でクラスタが単一のバックエンド＋コンピュートノードである場合にのみ検討されます。プランナーは安全でないケース（例：DISTINCT 集約、検出されたデータスキュー、欠落または不明なカラム統計、結合のような複数入力オペレータ、その他のセマンティック制約）ではローカルシャッフル変換を却下します。いくつかのコードパス（INSERT/UPDATE/DELETE のプランナーや MaterializedViewOptimizer）は、一時的にこのセッションフラグを無効化します。これは非クエリシンクや特定のリライトが driver 単位の scan アサインを要求し、ローカルシャッフルでは利用できないためです。
  • スコープ: セッション
  • デフォルト: true
  • データ型: boolean
  • 導入バージョン: v3.2.0

enable_materialized_view_agg_pushdown_rewrite​

  • 説明: マテリアライズドビュークエリ書き換えのための集計プッシュダウンを有効にするかどうか。true に設定されている場合、集計関数はクエリ実行中に Scan Operator にプッシュダウンされ、Join Operator が実行される前にマテリアライズドビューによって書き換えられます。これにより、Join によるデータ拡張が軽減され、クエリパフォーマンスが向上します。この機能のシナリオと制限の詳細については、Aggregation pushdown を参照してください。
  • デフォルト: false
  • 導入バージョン: v3.3.0

enable_materialized_view_for_insert​

  • 説明: StarRocks が INSERT INTO SELECT 文でクエリを書き換えることを許可するかどうか。
  • デフォルト: false、つまりそのようなシナリオでのクエリ書き換えはデフォルトで無効です。
  • 導入バージョン: v2.5.18, v3.0.9, v3.1.7, v3.2.2

enable_materialized_view_text_match_rewrite​

  • 説明: テキストベースのマテリアライズドビュー書き換えを有効にするかどうか。この項目が true に設定されている場合、オプティマイザはクエリを既存のマテリアライズドビューと比較します。マテリアライズドビューの定義の抽象構文ツリーがクエリまたはそのサブクエリと一致する場合、クエリは書き換えられます。
  • デフォルト: true
  • 導入バージョン: v3.2.5, v3.3.0

enable_materialized_view_union_rewrite​

  • 説明: マテリアライズドビューのユニオン書き換えを有効にするかどうか。この項目が true に設定されている場合、マテリアライズドビューの述語がクエリの述語を満たさない場合、システムは UNION ALL を使用して述語を補完しようとします。
  • デフォルト: true
  • 導入バージョン: v2.5.20, v3.1.9, v3.2.7, v3.3.0

enable_metadata_profile​

  • 説明: Iceberg Catalog のメタデータ収集クエリに対して Profile を有効にするかどうか。
  • デフォルト: true
  • 導入バージョン: v3.3.3

enable_multicolumn_global_runtime_filter​

マルチカラムグローバルランタイムフィルタを有効にするかどうか。デフォルト値: false、つまりマルチカラムグローバル RF は無効です。

ジョイン（Broadcast Join および Replicated Join を除く）に複数の等値ジョイン条件がある場合：

  • この機能が無効な場合、ローカル RF のみが機能します。
  • この機能が有効な場合、マルチカラムグローバル RF が有効になり、パーティション by 句に multi-column を含みます。

enable_mv_planner​

  • スコープ: Session
  • 説明: 有効にすると、現在のセッションに対して Materialized View (MV) planner モードを有効にします。このモードではオプティマイザは以下のように動作します：
    • 通常の join 実装ルール（QueryOptimizer）ではなく、context.getRuleSet().addRealtimeMVRules() を通じた MV 固有のルールセットを使用します。
    • stream 実装ルールが適用されることを許可します（StreamImplementationRule.check は MV planner がオンのときのみ true を返します）。
    • 論理プラン変換時の scan/operator 構築を変更します（例：RelationTransformer は MV planner が有効な場合、ネイティブテーブル/マテリアライズドビューに対して LogicalBinlogScanOperator を選択します）。
    • 一部の標準変換を無効化またはバイパスします（例：SplitMultiPhaseAggRule.check は MV planner がオンのとき false を返します）。 Materialized view のプラン生成コード（MaterializedViewAnalyzer）は MV プランニング作業の前後でこのフラグを設定します（プランニング前に true にし、終了後に false に戻す）ので、主に MV プラン生成とテスト用を意図しています。このセッション変数を設定しても、影響は現在のセッションのオプティマイザ動作にのみ及びます。
  • デフォルト: false
  • データ型: boolean
  • 導入バージョン: v3.2.0

enable_parallel_merge​

  • 説明: ソートの Parallel Merge を有効にするかどうか。この機能を有効にすると、ソートのマージフェーズでマージ操作に複数のスレッドが使用されます。
  • デフォルト: true
  • 導入バージョン: v3.3

enable_parquet_reader_bloom_filter​

  • デフォルト: true
  • データ型: Boolean
  • 単位: -
  • 説明: Parquet ファイルの読み込み時にブルームフィルターの最適化を有効にするかどうか。
    • true (デフォルト): Parquet ファイルの読み込み時にブルームフィルタの最適化を有効にする。
    • false: Parquet ファイルの読み込み時にブルームフィルターの最適化を有効にしない。
  • 導入バージョン: v3.5.0

enable_parquet_reader_page_index​

  • デフォルト: true
  • データ型: Boolean
  • 単位: -
  • 説明: Parquet ファイルの読み込み時にページインデックスの最適化を有効にするかどうか。
    • true (デフォルト): Parquet ファイルの読み込み時にページインデックスの最適化を有効にする。
    • false: Parquet ファイルの読み込み時にページインデックスの最適化を有効にしない。
  • 導入バージョン: v3.5.0

enable_partition_hash_join​

  • 説明: 適応型 Partition Hash Join を有効にするかどうか。
  • デフォルト: true
  • 導入バージョン: v3.4

enable_per_bucket_optimize​

  • 説明: バケット化計算を有効化するかどうか。この機能を有効にすると、第 1 段階の集計をバケット順に計算でき、メモリ使用量を削減できます。
  • デフォルト: true
  • 導入バージョン: v3.0

enable_phased_scheduler​

  • 説明: マルチフェーズスケジューリングを有効にするかどうか。マルチフェーズスケジューリングを有効にすると、フラグメントは依存関係に基づいてスケジューリングされます。例えば、システムはまず Shuffle Join の Build side のフラグメントをスケジュールし、次に Probe side のフラグメントをスケジュールします（注：ステージごとのスケジュールとは異なり、フェーズごとのスケジュールは依然として MPP 実行モード下で実行されます）。マルチフェーズスケジューリングを有効にすると、多数のUNION ALLクエリにおけるメモリ使用量を大幅に削減できます。
  • デフォルト: false
  • 導入バージョン: v3.3

enable_pipeline_engine​

  • 説明: パイプライン実行エンジンを有効にするかどうかを指定します。true は有効を示し、false は無効を示します。デフォルト値: true。
  • デフォルト: true

enable_plan_advisor​

  • 説明: 遅いクエリや手動でマークされたクエリに対するクエリフィードバック機能を有効にするかどうか。
  • デフォルト: true
  • 導入バージョン: v3.4.0

enable_predicate_reorder​

  • スコープ: Session
  • 説明: 有効にすると、オプティマイザは論理／物理プランの書き換え時に AND（連言）述語に対して Predicate Reorder ルールを適用します。ルールは Utils.extractConjuncts を使って連言の各項を抽出し、DefaultPredicateSelectivityEstimator で各項の選択性を推定し、推定選択性の昇順（制約の緩いものを先）で項を並べ替えて新しい CompoundPredicateOperator（AND）を構成します。オペレータが複数の項を持つ CompoundPredicateOperator の場合にのみルールは実行されます。統計は子の OptExpression の統計から取得され、PhysicalOlapScanOperator の場合は GlobalStateMgr.getCurrentState().getStatisticStorage() からカラム統計を取得します。子の統計が欠けておりスキャンが OLAP スキャンでない場合、ルールは並べ替えをスキップします。セッション変数は SessionVariable.isEnablePredicateReorder() を通じて公開され、enablePredicateReorder() および disablePredicateReorder() のヘルパーメソッドがあります。
  • デフォルト: false
  • データタイプ: boolean
  • 導入バージョン: v3.2.0

enable_profile​

  • 説明: クエリのプロファイルを分析のために送信するかどうかを指定します。デフォルト値は false で、プロファイルは必要ありません。

    デフォルトでは、クエリエラーが BE で発生した場合にのみプロファイルが FE に送信されます。プロファイルの送信はネットワークオーバーヘッドを引き起こし、高い並行性に影響を与えます。

    クエリのプロファイルを分析する必要がある場合、この変数を true に設定できます。クエリが完了した後、現在接続されている FE のウェブページ（アドレス：fe_host:fe_http_port/query）でプロファイルを表示できます。このページには、enable_profile がオンになっている最新の 100 件のクエリのプロファイルが表示されます。

  • デフォルト: false

enable_explain_in_profile​

  • スコープ: Session

  • 説明: この変数が true で、かつクエリに対してプロファイルが生成される場合、実行された計画の EXPLAIN COSTS テキストがプロファイルの Summary セクション内に ExplainPlan というキーで埋め込まれます。これにより、稼働中のクラスターにアクセスできない状態で保存済みのプロファイル成果物だけを使ってスロークエリを切り分ける際に、ランタイムメトリクスと並べてオプティマイザーの基数推定、列統計、述語、ランタイムフィルター宣言、および全体の計画コストを確認できます。

    プロファイルに埋め込まれる計画は、他の永続化される SQL 成果物と同じ非機密化制御に従います。FILES(...) などに含まれる資格情報リテラルは常に編集され、述語や射影のリテラルは、クラスター全体の FE 設定 enable_sql_desensitize_in_log またはセッション変数 enable_desensitize_explain のいずれかが有効な場合にダイジェスト形式で表示されます。

  • デフォルト: false

  • データ型: boolean

profile_log_latency_threshold_ms​

  • スコープ: Session
  • 説明: FE が fe.profile.log にプロファイルを書き込むための最小クエリレイテンシ（ミリ秒）。実行時間がこの値以上の場合にのみプロファイルを記録します。-1（デフォルト）に設定すると、FE 設定の profile_log_latency_threshold_ms が使用されます。0 に設定するとすべてのプロファイルを記録します。正の値（例: 1000）に設定すると、レイテンシがその値（ミリ秒）以上のクエリのみを記録します。このセッション変数で接続ごとにクラスタ全体の設定を上書きできます。
  • デフォルト: -1
  • データ型: long
  • 単位: ミリ秒

enable_query_cache​

  • 説明: Query Cache 機能を有効にするかどうかを指定します。有効な値: true および false。true はこの機能を有効にし、false はこの機能を無効にします。この機能が有効な場合、Query Cache の適用シナリオで指定された条件を満たすクエリに対してのみ機能します。
  • デフォルト: false
  • 導入バージョン: v2.5

enable_query_queue_load (global)​

  • 説明: ロードタスクのクエリキューを有効にするためのブール値。
  • デフォルト: false

enable_query_queue_select (global)​

  • 説明: SELECT クエリのクエリキューを有効にするかどうか。
  • デフォルト: false

enable_query_queue_statistic (global)​

  • 説明: 統計クエリのクエリキューを有効にするかどうか。
  • デフォルト: false

enable_query_tablet_affinity​

  • 説明: 同じタブレットに対する複数のクエリを固定レプリカに向けるかどうかを制御するためのブール値。

    クエリするテーブルに多数のタブレットがあるシナリオでは、この機能によりクエリパフォーマンスが大幅に向上します。なぜなら、タブレットのメタ情報とデータがメモリにより迅速にキャッシュされるからです。

    ただし、ホットスポットタブレットがある場合、この機能はクエリパフォーマンスを低下させる可能性があります。なぜなら、クエリを同じ BE に向けるため、高い並行性シナリオで複数の BE のリソースを十分に活用できなくなるからです。

  • デフォルト: false、つまりシステムは各クエリに対してレプリカを選択します。

  • 導入バージョン: v2.5.6, v3.0.8, v3.1.4, および v3.2.0

enable_query_trigger_analyze​

  • デフォルト: true
  • タイプ: Boolean
  • 説明: 外部テーブルに対してクエリトリガー ANALYZE タスクを有効化するかどうか。
  • 導入バージョン: v3.4.0

enable_rbo_table_prune​

  • 説明: セッションで有効にすると、オプティマイザは現在のセッションでカーディナリティを保持する結合に対してルールベース（RBO）によるテーブルプルーニングを適用します。オプティマイザは一連のリライトおよびプルーニングステップ（パーティションプルーニング、project のマージ/分離、UniquenessBasedTablePruneRule、結合順序入れ替え、RboTablePruneRule）を実行して不要なテーブルスキャンの候補を除去し、結合における走査パーティション/行数を削減します。このオプションを有効にすると、論理ルールのリライト実行中に競合する変換を避けるために結合同値性導出（context.setEnableJoinEquivalenceDerive(false)）が無効化されます。プルーニングフローは、enable_table_prune_on_update が設定されている場合に UPDATE 文に対して PrimaryKeyUpdateTableRule を追加で実行することがあります。ルールは、クエリがプルーニング可能な結合を含む場合にのみ実行されます（Utils.hasPrunableJoin(tree) でチェックされます）。
  • スコープ: Session
  • デフォルト: false
  • タイプ: boolean
  • 導入バージョン: v3.2.0

enable_runtime_adaptive_dop​

  • スコープ: Session
  • 説明: セッションで有効にすると、planner と fragment builder はランタイムの adaptive DOP をサポートするパイプライン対応フラグメントに対して、実行時に adaptive degree-of-parallelism を使用するようマークします。このオプションは enable_pipeline_engine が true のときのみ有効になります。有効にするとフラグメントはプラン構築中に enableAdaptiveDop() を呼び出すようになり、ランタイム上の影響があります：join の probe はすべての build フェーズが完了するのを待つ可能性があり（これは group_execution の動作と衝突します）、ランタイム adaptive DOP を有効にするとパイプラインレベルの multi-partitioned runtime filters が無効になります（setter は enablePipelineLevelMultiPartitionedRf をクリアします）。このフラグはクエリプロファイルに記録され、セッション単位で切り替えることができます。
  • デフォルト: false
  • データ型: boolean
  • 導入バージョン: v3.2.0

enable_scan_datacache​

  • 説明: Data Cache 機能を有効にするかどうかを指定します。この機能が有効になると、StarRocks は外部ストレージシステムから読み取ったホットデータをブロックにキャッシュし、クエリと分析を加速します。詳細については、Data Cache を参照してください。バージョン 3.2 より前では、この変数は enable_scan_block_cache として名前が付けられていました。
  • デフォルト: true
  • 導入バージョン: v2.5

enable_short_circuit​

  • 説明: クエリのショートサーキットを有効にするかどうか。デフォルト: false。true に設定されている場合、クエリが条件を満たすとき（クエリがポイントクエリであるかどうかを評価するための条件）、WHERE 句の条件列がすべての主キー列を含み、WHERE 句の演算子が = または IN の場合、クエリはショートサーキットを取ります。
  • デフォルト: false
  • 導入バージョン: v3.2.3

enable_sort_aggregate​

  • 説明: ソートされたストリーミングを有効にするかどうかを指定します。true はソートされたストリーミングが有効で、データストリーム内のデータをソートします。
  • デフォルト: false
  • 導入バージョン: v2.5

enable_spill​

  • 説明: 中間結果のスピルを有効にするかどうか。デフォルト: false。true に設定されている場合、StarRocks はクエリ内の集計、ソート、またはジョインオペレーターを処理する際にメモリ使用量を削減するために中間結果をディスクにスピルします。
  • デフォルト: false
  • 導入バージョン: v3.0

enable_spill_to_remote_storage​

  • 説明: 中間結果をオブジェクトストレージにスピルするかどうか。true に設定されている場合、StarRocks はローカルディスクの容量制限に達した後、spill_storage_volume で指定されたストレージボリュームに中間結果をスピルします。
  • デフォルト: false
  • 導入バージョン: v3.3.0

enable_spm_rewrite​

  • 説明: SQL Plan Manager (SPM) クエリ改写を有効にするかどうか。有効にすると、StarRocks は自動的にクエリを拘束されたクエリプランに改写し、クエリのパフォーマンスと安定性を向上させます。
  • デフォルト: false

enable_strict_order_by​

  • 説明: ORDER BY で参照される列名が曖昧であるかどうかをチェックするために使用されます。この変数がデフォルト値 TRUE に設定されている場合、次のようなクエリパターンに対してエラーが報告されます：クエリの異なる式で重複したエイリアスが使用され、このエイリアスが ORDER BY のソートフィールドでもある場合、例：select distinct t1.* from tbl1 t1 order by t1.k1;。このロジックは v2.3 およびそれ以前と同じです。この変数が FALSE に設定されている場合、緩やかな重複排除メカニズムが使用され、そのようなクエリを有効な SQL クエリとして処理します。
  • デフォルト: true
  • 導入バージョン: v2.5.18 および v3.1.7

enable_sync_materialized_view_rewrite​

  • 説明: 同期マテリアライズドビューに基づくクエリの書き換えを有効にするかどうか。
  • デフォルト: true
  • 導入バージョン: v3.1.11, v3.2.5

enable_table_prune_on_update​

  • 説明: セッションレベルのブールで、オプティマイザが UPDATE 文に対して主キー固有のテーブルプルーニング規則を適用するかどうかを制御します。有効にすると、QueryOptimizer（pruneTables ステージ中）が PrimaryKeyUpdateTableRule を呼び出して更新プランを書き換え／プルーニングし、主キー更新パターンに対するプルーニングを改善する可能性があります。このフラグは rule-based/CBO によるテーブルプルーニングが有効な場合にのみ効果があります（enable_rbo_table_prune を参照）。デフォルトで無効になっているのは、この変換がデータレイアウトやプランの形状（例：OlapTableSink のバケットシャッフルレイアウト）を変える可能性があり、同時更新時に正確性や性能の後退を引き起こす恐れがあるためです。
  • デフォルト: false
  • データタイプ: boolean
  • 導入バージョン: v3.2.4

enable_tablet_internal_parallel​

  • 説明: タブレットの適応並列スキャンを有効にするかどうか。この機能を有効にすると、複数のスレッドを使用してタブレットをセグメントごとにスキャンし、スキャンの並行性を高めることができます。
  • デフォルト: true
  • 導入バージョン: v2.3

enable_tablet_pre_split​

  • 説明: サンプリングベースのタブレット事前分割（Sample-Based Tablet Pre-Split）に対するセッション単位のオプトアウト。FE Config ゲート（enable_tablet_pre_split_for_*）を主たるオン／オフスイッチとして機能させるため、既定値は true です。特定のセッションの取り込みに干渉させたくない場合は false に設定してください。事前分割が実行されるには、対応する Config フラグとこのセッション変数の両方が true である必要があります。
  • デフォルト: true
  • 導入バージョン: v4.1.0

enable_topn_runtime_filter​

  • 説明: TopN Runtime Filter を有効にするかどうか。この機能を有効にすると、ORDER BY LIMIT クエリに対して動的に Runtime Filter が構築され、Scan 段階にプッシュダウンされてフィルタリングに利用されます。
  • デフォルト: true
  • 導入バージョン: v3.3

enable_ukfk_opt​

  • 説明: Unique-Key / Foreign-Key (UK/FK) に基づく変換と統計の拡張に対するオプティマイザのサポートを有効にします。有効にすると、オプティマイザは UKFKConstraintsCollector を実行して一番下から（bottom‑up に）ユニークキーおよび外部キー制約を収集し、それらを計画ノード（OptExpressions）に付加します。収集された制約は PruneUKFKJoinRule（結合の UK 側をプルーニングしたり、述語を UK から FK 列へ書き換え、外部結合の場合に IS NULL チェックを追加する）や PruneUKFKGroupByKeysRule（UK/FK 関係から導出される冗長な GROUP BY キーを削除する）などの変換ルールで利用されます。収集された UK/FK 情報は StatisticsCalculator において UK‑FK ジョインの結合基数推定をより厳密にするためにも使われ、より精密な場合はデフォルトの推定を置き換えることがあります。これらの最適化は宣言されたスキーマ制約に依存し、プランの形状や述語の配置を変更する可能性があるため、デフォルトは保守的に false です。
  • デフォルト: false
  • スコープ: セッション
  • データタイプ: boolean
  • 導入バージョン: v3.2.4

enable_vector_index_refine​

  • 説明: 量子化ベクターインデックスが返した候補について、元のベクトルから正確な距離を再計算し、再順位付けするかどうかを指定します。IVFPQ、および sq4、sq8、pq 量子化器を使用する HNSW インデックスに適用されます。量子化されていない HNSW インデックス（quantizer = flat）には影響しません。有効にすると結果の精度が向上する可能性がありますが、I/O と計算コストが増加します。EXPLAIN の Refine: ON/OFF で有効かどうかを確認できます。
  • デフォルト: false
  • データ型: Boolean
  • スコープ: Session

enable_vector_index_split_at_segment_boundary​

  • 説明: Tablet 内並列スキャンを使用する場合に、ベクタークエリの分割点が Segment 境界に揃うかどうかを指定します。ベクターインデックスは Segment ごとに検索されるため、Segment の内部で分割すると、生成された各サブタスクがそれぞれの行範囲に対して同じインデックス全体を再度検索することになります。この変数は分割点の位置を制約するものであり、どの分割方式を使うかを変えるものではありません。また、ベクターインデックスを使用しないクエリには影響しません。false に設定すると行数による分割に戻り、インデックス検索がサブタスクの数だけ繰り返されます。
  • デフォルト: true
  • データ型: Boolean
  • スコープ: Session

enable_view_based_mv_rewrite​

  • 説明: ビューに基づくマテリアライズドビューのクエリ書き換えを有効にするかどうか。この項目が true に設定されている場合、ビューは統一されたノードとして使用され、クエリのパフォーマンスを向上させるために自身に対するクエリを書き換えます。この項目が false に設定されている場合、システムはビューに対するクエリを物理テーブルまたはマテリアライズドビューに対するクエリに書き換えます。
  • デフォルト: false
  • 導入バージョン: v3.1.9, v3.2.5, v3.3.0

enable_wait_dependent_event​

  • 説明: パイプラインが、同じフラグメント内で依存するオペレーターの実行が完了するまで待機するかどうか。例えば、Left Join クエリにおいて、この機能が有効になっている場合、Probe side オペレーターは Build side オペレーターの実行が完了するまで待機し、その後実行を開始します。この機能を有効にするとメモリ使用量を削減できますが、クエリの遅延が増加する可能性があります。ただし、CTE で再利用されるクエリの場合、この機能を有効にするとメモリ使用量が増加する可能性があります。
  • デフォルト: false
  • 導入バージョン: v3.3

enable_write_hive_external_table​

  • 説明: Hive の外部テーブルにデータをシンクすることを許可するかどうか。
  • デフォルト: false
  • 導入バージョン: v3.2

event_scheduler​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

forward_to_leader​

一部のコマンドがリーダー FE に転送されて実行されるかどうかを指定するために使用されます。エイリアス: forward_to_master。デフォルト値は false で、リーダー FE に転送されません。StarRocks クラスタには複数の FE があり、そのうちの 1 つがリーダー FE です。通常、ユーザーは任意の FE に接続してフル機能の操作を行うことができます。ただし、一部の情報はリーダー FE にのみ存在します。

たとえば、SHOW BACKENDS コマンドがリーダー FE に転送されない場合、ノードが生存しているかどうかなどの基本情報のみを表示できます。リーダー FE に転送すると、ノードの起動時間や最終ハートビート時間などの詳細情報を取得できます。

この変数に影響を受けるコマンドは次のとおりです：

  • SHOW FRONTENDS: リーダー FE に転送すると、ユーザーは最終ハートビートメッセージを表示できます。

  • SHOW BACKENDS: リーダー FE に転送すると、ユーザーは起動時間、最終ハートビート情報、ディスク容量情報を表示できます。

  • SHOW BROKER: リーダー FE に転送すると、ユーザーは起動時間と最終ハートビート情報を表示できます。

  • SHOW TABLET

  • ADMIN SHOW REPLICA DISTRIBUTION

  • ADMIN SHOW REPLICA STATUS: リーダー FE に転送すると、ユーザーはリーダー FE のメタデータに保存されているタブレット情報を表示できます。通常、タブレット情報は異なる FE のメタデータで同じであるべきです。エラーが発生した場合、この方法を使用して現在の FE とリーダー FE のメタデータを比較できます。

  • Show PROC: リーダー FE に転送すると、ユーザーはメタデータに保存されている PROC 情報を表示できます。これは主にメタデータの比較に使用されます。

group_concat_max_len​

  • 説明: group_concat 関数によって返される文字列の最大長。
  • デフォルト: 1024
  • 最小値: 4
  • 単位: 文字
  • データ型: Long

group_execution_max_groups​

  • 説明: Group Execution で許可されるグループの最大数。分割の粒度を制限し、過剰なグループ数によるスケジューリングのオーバーヘッドを防ぐために使用されます。
  • デフォルト: 128
  • 導入バージョン: v3.3

group_execution_min_scan_rows​

  • 説明: Group Execution におけるグループごとの最小処理行数。
  • デフォルト: 5000000
  • 導入バージョン: v3.3

hash_join_push_down_right_table​

  • 説明: ジョインクエリで右テーブルに対するフィルタ条件を使用して左テーブルのデータをフィルタリングできるかどうかを制御するために使用されます。これにより、クエリ中に処理する必要のあるデータ量を削減できます。
  • デフォルト: true は操作が許可され、システムが左テーブルをフィルタリングできるかどうかを決定します。false は操作が無効です。デフォルト値は true です。

historical_nodes_min_update_interval​

  • 説明: ヒストリカルノード記録の2回の更新の間の最小間隔。クラスタのノードが短期間で頻繁に変更される場合（つまり、この変数で設定された値未満）、いくつかの中間状態は有効なヒストリカルノードスナップショットとして記録されません。ヒストリカルノードは、クラスタのスケーリング中に適切なキャッシュノードを選択するためのキャッシュ共有機能の主な基盤となります。
  • デフォルト: 600
  • 単位: Seconds
  • 導入バージョン: v3.5.1

init_connect (global)​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

innodb_read_only​

  • 説明: セッションレベルのフラグ（MySQL 互換）で、セッションの InnoDB 読み取り専用モードを示します。この変数は SessionVariable.java の Java フィールド innodbReadOnly として宣言およびセッションに保存され、isInnodbReadOnly() および setInnodbReadOnly(boolean) を介してアクセス可能です。SessionVariable クラスはフラグを保持するだけであり、実際の強制（InnoDB テーブルへの書き込み/DDL の防止やトランザクション動作の変更など）は、このセッションフラグを参照すべきトランザクション／ストレージ／認可レイヤー側で実装する必要があります。現在のセッション内で読み取り専用の意図を伝えるために、この変数を使用してください。
  • スコープ: Session
  • デフォルト: true
  • データ型: boolean
  • 導入バージョン: v3.2.0

insert_max_filter_ratio​

  • 説明: Files() からの INSERT の最大エラー許容率。データ品質が不十分なためにフィルタリングされるデータレコードの最大比率です。不適格なデータレコードの比率がこのしきい値に達すると、ジョブは失敗します。範囲: [0, 1]。
  • デフォルト: 0
  • 導入バージョン: v3.4.0

insert_timeout​

  • 説明: INSERT ジョブのタイムアウト時間。単位: 秒。v3.4.0 以降、insert_timeout は INSERT に関与する操作（例: UPDATE、DELETE、CTAS、マテリアライズドビューのリフレッシュ、統計収集、PIPE）に適用され、query_timeout を置き換えます。
  • デフォルト: 14400
  • 導入バージョン: v3.4.0

interactive_timeout​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

io_tasks_per_scan_operator​

  • 説明: スキャンオペレーターによって発行される同時 I/O タスクの数。この値を増やすと、HDFS や S3 などのリモートストレージシステムにアクセスする際のレイテンシーが高い場合に役立ちます。ただし、値が大きいとメモリ消費が増加します。
  • デフォルト: 4
  • データ型: Int
  • 導入バージョン: v2.5

jit_level​

  • 説明: 式の JIT コンパイルが有効になるレベル。有効な値:
    • 1: システムはコンパイル可能な式に対して適応的に JIT コンパイルを有効にします。
    • -1: JIT コンパイルはすべてのコンパイル可能な非定数式に対して有効です。
    • 0: JIT コンパイルは無効です。この機能にエラーが発生した場合、手動で無効にすることができます。
  • デフォルト: 1
  • データ型: Int
  • 導入バージョン: -

k_factor​

  • 説明: クエリの LIMIT にこの値を掛け、各 Segment が返すベクターインデックス候補数を決定します。1 より大きい値は、複数 Segment の候補をマージした後の再現率を向上させる可能性がありますが、インデックス検索、メモリ、および後続処理のコストが増加します。最終的な候補数は少なくとも 1 に調整されます。
  • デフォルト: 1
  • データ型: Double
  • スコープ: Session

lake_bucket_assign_mode​

  • 説明: データレイク内のテーブルに対するクエリにおけるバケット割り当てモード。この変数は、クエリ実行中に Bucket-aware 実行が有効になった際に、バケットがワーカーノードにどのように割り当てられるかを制御します。有効な値:
    • balance: ワーカーノードにバケットを均等に割り当て、バランスの取れたワークロードとより良いパフォーマンスを実現します。
    • elastic: 一貫性ハッシュを使用してバケットをワーカーノードに割り当て、弾力的な環境においてより良い負荷分散を実現できます。
  • デフォルト: balance
  • タイプ: String
  • 導入バージョン: v4.0

language (global)​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

license (global)​

  • 説明: StarRocks のライセンスを表示します。
  • デフォルト: Apache License 2.0

load_mem_limit​

インポート操作のメモリ制限を指定します。デフォルト値は 0 で、この変数は使用されず、query_mem_limit が代わりに使用されます。

この変数は、クエリとインポートの両方を含む INSERT 操作にのみ使用されます。ユーザーがこの変数を設定しない場合、クエリとインポートのメモリ制限は exec_mem_limit に設定されます。それ以外の場合、クエリのメモリ制限は exec_mem_limit に設定され、インポートのメモリ制限は load_mem_limit に設定されます。

他のインポート方法（BROKER LOAD、STREAM LOAD など）は引き続き exec_mem_limit をメモリ制限として使用します。

log_rejected_record_num (v3.1 以降)​

ログに記録できる不適格なデータ行の最大数を指定します。有効な値: 0、-1、および任意の非ゼロ正の整数。デフォルト値: 0。

  • 値 0 は、フィルタリングされたデータ行がログに記録されないことを指定します。
  • 値 -1 は、フィルタリングされたすべてのデータ行がログに記録されることを指定します。
  • 非ゼロ正の整数 n は、フィルタリングされたデータ行が各 BE で最大 n 行までログに記録されることを指定します。

low_cardinality_optimize_on_lake​

  • デフォルト: true
  • データ型: Boolean
  • 単位: -
  • 説明: データレイクのクエリで低基数最適化を有効にするかどうか。有効な値：
    • true (デフォルト)：データレイクのクエリで低基数最適化を有効にします。
    • false：データレイクのクエリで低基数最適化を無効にします。
  • 導入バージョン: v3.5.0

low_cardinality_optimize_v2​

  • スコープ: Session
  • 説明: オプティマイザが適用する low-cardinality 最適化のどのリライトを選択するかを制御するセッションレベルの boolean。true の場合、オプティマイザは LowCardinalityRewriteRule によって実装された新しい V2 リライト（DecodeCollector / DecodeRewriter を使用して low-cardinality な VARCHAR カラムをエンコード/デコード）を試行します。false の場合、オプティマイザは AddDecodeNodeForDictStringRule によって実装されたレガシーなリライトにフォールバックします。どちらのリライトを実行する場合でも enableLowCardinalityOptimize が有効である必要があり、enableLowCardinalityOptimize が無効な場合は low-cardinality のリライトは実行されません。この変数は適切な変換を選択するためにオプティマイザのツリー書き換え経路でチェックされます。
  • デフォルト: true
  • タイプ: boolean
  • 導入バージョン: v3.3.0, v3.4.0, v3.5.0

lower_case_table_names (global)​

MySQL クライアント互換性のために使用されます。実際の用途はありません。StarRocks のテーブル名は大文字小文字を区別します。

materialized_view_rewrite_mode (v3.2 以降)​

非同期マテリアライズドビューのクエリ書き換えモードを指定します。有効な値:

  • disable: 非同期マテリアライズドビューの自動クエリ書き換えを無効にします。
  • default（デフォルト値）: 非同期マテリアライズドビューの自動クエリ書き換えを有効にし、オプティマイザがコストに基づいてクエリをマテリアライズドビューを使用して書き換えるかどうかを決定します。クエリが書き換えられない場合、ベーステーブルのデータを直接スキャンします。
  • default_or_error: 非同期マテリアライズドビューの自動クエリ書き換えを有効にし、オプティマイザがコストに基づいてクエリをマテリアライズドビューを使用して書き換えるかどうかを決定します。クエリが書き換えられない場合、エラーが返されます。
  • force: 非同期マテリアライズドビューの自動クエリ書き換えを有効にし、オプティマイザがマテリアライズドビューを使用してクエリを書き換えることを優先します。クエリが書き換えられない場合、ベーステーブルのデータを直接スキャンします。
  • force_or_error: 非同期マテリアライズドビューの自動クエリ書き換えを有効にし、オプティマイザがマテリアライズドビューを使用してクエリを書き換えることを優先します。クエリが書き換えられない場合、エラーが返されます。

materialized_view_subquery_text_match_max_count​

  • 説明: クエリのサブクエリがマテリアライズドビューの定義と一致するかどうかをシステムがチェックする最大回数を指定します。
  • デフォルト: 4
  • 導入バージョン: v3.2.5, v3.3.0

max_allowed_packet​

  • 説明: JDBC 接続プール C3P0 との互換性のために使用されます。この変数は、クライアントとサーバー間で送信できるパケットの最大サイズを指定します。
  • デフォルト: 33554432 (32 MB)。クライアントが "PacketTooBigException" を報告する場合、この値を増やすことができます。
  • 単位: バイト
  • データ型: Int

max_pipeline_dop​

  • スコープ: Session
  • 説明: パイプラインエンジンの degree-of-parallelism (DOP) に対するセッションごとの上限。動作:
    • enable_pipeline_engine が有効で pipeline_dop が明示的に設定されていない（0 以下ではない）場合にのみ適用されます。pipeline_dop が 0 より大きい場合、この変数は無視され pipeline_dop が直接使用されます。
    • pipeline_dop が 0 以下（アダプティブ/デフォルトモード）のとき、実際の実行 DOP は min(max_pipeline_dop, BackendResourceStat が返すバックエンドのデフォルト DOP) として計算されます。パイプラインの sink に対しては同じロジックで sink のデフォルト DOP が使用されます。
    • max_pipeline_dop が 0 以下の場合、追加の上限は適用されずバックエンドのデフォルト DOP が使用されます。
    • 目的: コア数が非常に多いマシンでスケジューリングによる負荷増を回避するため、自動計算された並列度に上限をかけること。
  • デフォルト: 64
  • データ型: int
  • 導入バージョン: v3.2.0

max_pushdown_conditions_per_column​

  • 説明: 列に対してプッシュダウンできる述語の最大数。
  • デフォルト: -1、be.conf ファイルの値が使用されることを示します。この変数が 0 より大きい値に設定されている場合、be.conf の値は無視されます。
  • データ型: Int

max_scan_key_num​

  • 説明: 各クエリによってセグメント化されるスキャンキーの最大数。
  • デフォルト: -1、be.conf ファイルの値が使用されることを示します。この変数が 0 より大きい値に設定されている場合、be.conf の値は無視されます。

metadata_collect_query_timeout​

  • 説明: Iceberg Catalog メタデータ収集クエリのタイムアウト時間。
  • 単位: 秒
  • デフォルト: 60
  • 導入バージョン: v3.3.3

nested_mv_rewrite_max_level​

  • 説明: クエリ書き換えに使用できるネストされたマテリアライズドビューの最大レベル。
  • 値の範囲: [1, +∞)。値 1 は、ベーステーブルに作成されたマテリアライズドビューのみがクエリ書き換えに使用できることを示します。
  • デフォルト: 3
  • データ型: Int

net_buffer_length​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

net_read_timeout​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

net_write_timeout​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

new_planner_optimize_timeout​

  • 説明: クエリオプティマイザのタイムアウト時間。オプティマイザがタイムアウトすると、エラーが返され、クエリが停止され、クエリパフォーマンスに影響を与えます。この変数をクエリに基づいて大きな値に設定するか、StarRocks の技術サポートに連絡してトラブルシューティングを行うことができます。タイムアウトは、クエリにジョインが多すぎる場合に発生することがあります。
  • デフォルト: 3000
  • 単位: ms

one_tablet_opt_max_tablet_rows​

  • 説明: Tablet のサイズに基づいて単一 Tablet 最適化を制御します。クエリが単一の Tablet に絞り込まれると、StarRocks は集計を 1 フェーズで実行し、結果を単一ノードに集約して Shuffle を省略できます。小さな Tablet には効率的ですが、Tablet が大きい場合はクエリ全体を単一ノードで直列化します。選択された単一 Tablet の行数がこのしきい値を超える場合、この最適化は無効になり、通常の分散（Shuffle）プランが使用されます。-1 に設定すると、このゲートが無効になり、Tablet のサイズに関係なく常に単一 Tablet 最適化が適用されます。
  • デフォルト: 10000000
  • データ型: Long
  • 導入バージョン: v4.2

optimizer_materialized_view_timelimit​

  • 説明: マテリアライズドビューの書き換えルールが消費できる最大時間を指定します。しきい値に達すると、このルールはクエリ書き換えに使用されません。
  • デフォルト: 1000
  • 単位: ms
  • 導入バージョン: v3.1.9, v3.2.5

orc_use_column_names​

  • 説明: StarRocks が Hive から ORC ファイルを読み取る際に列がどのように一致するかを指定するために使用されます。デフォルト値は false で、ORC ファイル内の列は Hive テーブル定義内の順序位置に基づいて読み取られます。この変数が true に設定されている場合、列は名前に基づいて読み取られます。
  • デフォルト: false
  • 導入バージョン: v3.1.10

parallel_exchange_instance_num​

上位ノードが実行プランで下位ノードからデータを受け取るために使用するエクスチェンジノードの数を設定するために使用されます。デフォルト値は -1 で、エクスチェンジノードの数は下位ノードの実行インスタンスの数と等しいことを意味します。この変数が 0 より大きく、下位ノードの実行インスタンスの数より小さい場合、エクスチェンジノードの数は設定値と等しくなります。

分散クエリ実行プランでは、上位ノードには通常、下位ノードの実行インスタンスからデータを受け取るための 1 つ以上のエクスチェンジノードがあります。通常、エクスチェンジノードの数は下位ノードの実行インスタンスの数と等しいです。

集計クエリシナリオで、集計後にデータ量が大幅に減少する場合、この変数を小さい値に変更してリソースオーバーヘッドを削減することができます。例として、重複キーテーブルを使用して集計クエリを実行することが挙げられます。

parallel_fragment_exec_instance_num​

各 BE でノードをスキャンするために使用されるインスタンスの数を設定するために使用されます。デフォルト値は 1 です。

クエリプランは通常、一連のスキャン範囲を生成します。このデータは複数の BE ノードに分散されています。BE ノードには 1 つ以上のスキャン範囲があり、デフォルトでは各 BE ノードのスキャン範囲セットは 1 つの実行インスタンスによって処理されます。マシンリソースが十分な場合、この変数を増やして、より多くの実行インスタンスがスキャン範囲を同時に処理できるようにすることで効率を向上させることができます。

スキャンインスタンスの数は、上位レベルの他の実行ノード（集計ノードやジョインノードなど）の数を決定します。したがって、クエリプラン実行全体の並行性を高めます。この変数を変更することで効率を向上させることができますが、値が大きいとマシンリソース（CPU、メモリ、ディスク IO など）が多く消費されます。

parallel_merge_late_materialization_mode​

  • 説明: ソートの Parallel Merge の遅延マテリアライゼーションモード。有効な値：
    • AUTO
    • ALWAYS
    • NEVER
  • デフォルト: AUTO
  • 導入バージョン: v3.3

partial_update_mode​

  • 説明: 部分更新のモードを制御するために使用されます。有効な値:

    • auto（デフォルト）: システムは UPDATE 文と関与する列を分析して部分更新のモードを自動的に決定します。
    • column: 部分更新にカラムモードを使用します。これは、少数の列と多数の行を含む部分更新に特に適しています。

    詳細については、UPDATE を参照してください。

  • デフォルト: auto

  • 導入バージョン: v3.1

performance_schema (global)​

MySQL JDBC バージョン 8.0.16 以降との互換性のために使用されます。実際の用途はありません。

phased_scheduler_max_concurrency​

  • 説明: フェーズドスケジューラーによるリーフノード フラグメントのスケジューリングにおける並列処理。例えば、デフォルト値は、多数の UNION ALL スキャン クエリにおいて、同時にスケジューリングされるスキャン フラグメントは最大で 2 つまで許可されることを意味します。
  • デフォルト: 2
  • 導入バージョン: v3.3

pipeline_dop​

  • 説明: パイプラインインスタンスの並行性を指定し、クエリの並行性を調整します。デフォルト値: 0、システムが各パイプラインインスタンスの並行性を自動的に調整することを示します。この変数は、OLAP テーブルへのロードジョブの並列処理も制御します。この変数を 0 より大きい値に設定することもできます。一般的に、物理 CPU コア数の半分の値に設定します。v3.0 以降、StarRocks はクエリの並行性に基づいてこの変数を適応的に調整します。

  • デフォルト: 0

  • データ型: Int

pipeline_profile_level​

  • 説明: クエリプロファイルのレベルを制御します。クエリプロファイルには通常、フラグメント、フラグメントインスタンス、パイプライン、パイプラインドライバー、オペレーターの 5 つのレイヤーがあります。異なるレベルはプロファイルの異なる詳細を提供します：

    • 0: StarRocks はプロファイルのメトリクスを結合し、いくつかのコアメトリクスのみを表示します。
    • 1: デフォルト値。StarRocks はプロファイルを簡略化し、プロファイルのメトリクスを結合してプロファイルレイヤーを減らします。
    • 2: StarRocks はプロファイルのすべてのレイヤーを保持します。このシナリオでは、特に SQL クエリが複雑な場合、プロファイルサイズが大きくなります。この値は推奨されません。

  • デフォルト: 1

  • データ型: Int

pipeline_sink_dop​

  • 説明: Iceberg テーブルおよび Hive テーブルへのデータロードにおけるシンクの並列処理、ならびに INSERT INTO FILES() を使用したデータアンロードの並列処理。これらのロードジョブの同時実行数を調整するために使用されます。デフォルト値：0（システムが自動的に並列処理を調整することを示します）。この変数を 0 より大きい値に設定することも可能です。
  • デフォルト: 0
  • データ型: Int

plan_mode​

  • 説明: Iceberg Catalog のメタデータ取得戦略。詳細は Iceberg Catalog metadata retrieval strategy を参照してください。有効な値:
    • auto: システムが自動的に取得プランを選択します。
    • local: FE がローカルで Iceberg manifest ファイルを解析し、解析しながら scan range を段階的に BE に配信します。すべての manifest の解析完了を待つ必要がなく、メモリ使用量と初回レイテンシを削減できます。
    • distributed: manifest の解析を複数の BE に分散して並列処理しますが、FE はすべての BE の結果が揃うまで scan range を配信できません。manifest ファイルが多い大規模テーブルでは、メモリ使用量の増大と待ち時間の長期化を招く可能性があります。FE の CPU がボトルネックになっている場合にのみ推奨します。
  • デフォルト: local（v3.5 より auto から変更。v3.5 以降、増分 scan range 配信がデフォルトで有効になったため、local モードはほとんどのワークロードで distributed より低メモリ・低レイテンシで動作します）
  • 導入バージョン: v3.3.3

populate_datacache_mode​

  • 説明: 外部ストレージシステムからデータブロックを読み取る際の Data Cache のポピュレーション動作を指定します。有効な値:
    • auto（デフォルト）: システムはポピュレーションルールに基づいてデータを選択的にキャッシュします。
    • always: 常にデータをキャッシュします。
    • never: データをキャッシュしません。
  • デフォルト: auto
  • 導入バージョン: v3.3.2

pq_refine_factor​

  • 説明: enable_vector_index_refine を有効にしたベクター範囲検索で使用する追加の候補倍率です。k_factor の後に適用されます。値を大きくすると、正確な距離による再順位付け前の再現率が向上する可能性がありますが、インデックス検索、I/O、および距離計算のコストが増加します。
  • デフォルト: 1
  • データ型: Double
  • スコープ: Session

query_cache_agg_cardinality_limit​

  • 説明: Query Cache における GROUP BY の基数の上限。GROUP BY によって生成される行がこの値を超える場合、Query Cache は有効になりません。デフォルト値: 5000000。query_cache_entry_max_bytes または query_cache_entry_max_rows が 0 に設定されている場合、関与するタブレットから計算結果が生成されていない場合でもパススルーモードが使用されます。
  • デフォルト: 5000000
  • データ型: Long
  • 導入バージョン: v2.5

query_cache_entry_max_bytes​

  • 説明: パススルーモードをトリガーするしきい値。特定のタブレットがアクセスするクエリの計算結果のバイト数または行数が query_cache_entry_max_bytes または query_cache_entry_max_rows で指定されたしきい値を超えると、クエリはパススルーモードに切り替わります。
  • 有効な値: 0 から 9223372036854775807 まで
  • デフォルト: 4194304
  • 単位: バイト
  • 導入バージョン: v2.5

query_cache_entry_max_rows​

  • 説明: キャッシュできる行の上限。query_cache_entry_max_bytes の説明を参照してください。デフォルト値: 。
  • デフォルト: 409600
  • 導入バージョン: v2.5

query_cache_size (global)​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

query_cache_type​

JDBC 接続プール C3P0 との互換性のために使用されます。実際の用途はありません。

query_mem_limit​

  • 説明: 各 BE ノードでのクエリのメモリ制限を設定するために使用されます。デフォルト値は 0 で、制限がないことを意味します。この項目はパイプラインエンジンが有効になった後にのみ有効です。Memory Exceed Limit エラーが発生した場合、この変数を増やすことができます。0 に設定すると、制限が課されないことを示します。
  • デフォルト: 0
  • 単位: バイト

query_queue_concurrency_limit (global)​

  • 説明: BE 上の同時クエリの上限。0 より大きい値に設定された場合にのみ有効です。0 に設定すると、制限が課されないことを示します。
  • デフォルト: 0
  • データ型: Int

query_queue_cpu_used_permille_limit (global)​

  • 説明: BE 上の CPU 使用率の上限（CPU 使用率 * 1000）。0 より大きい値に設定された場合にのみ有効です。0 に設定すると、制限が課されないことを示します。
  • 値の範囲: [0, 1000]
  • デフォルト: 0

query_queue_max_queued_queries (global)​

  • 説明: キュー内のクエリの上限。このしきい値に達すると、受信クエリは拒否されます。0 より大きい値に設定された場合にのみ有効です。0 に設定すると、制限が課されないことを示します。
  • デフォルト: 1024

query_queue_mem_used_pct_limit (global)​

  • 説明: BE 上のメモリ使用率の上限。0 より大きい値に設定された場合にのみ有効です。0 に設定すると、制限が課されないことを示します。
  • 値の範囲: [0, 1]
  • デフォルト: 0

query_queue_pending_timeout_second (global)​

  • 説明: キュー内の保留中のクエリの最大タイムアウト。このしきい値に達すると、対応するクエリは拒否されます。
  • デフォルト: 300
  • 単位: 秒

query_timeout​

  • 説明: クエリのタイムアウトを「秒」で設定するために使用されます。この変数は、現在の接続のすべてのクエリ文に影響を与えます。デフォルト値は 300 秒です。v3.4.0以降では、query_timeoutは INSERT を含む操作（例えば、UPDATE、DELETE、CTAS、マテリアライズドビューの更新、統計情報の収集、PIPE）には適用されません。
  • 値の範囲: [1, 259200]
  • デフォルト: 300
  • データ型: Int
  • 単位: 秒

range_pruner_max_predicate​

  • 説明: 範囲パーティションプルーニングに使用できる IN 述語の最大数。デフォルト値: 100。100 より大きい値は、システムがすべてのタブレットをスキャンする可能性があり、クエリパフォーマンスを損なう可能性があります。
  • デフォルト: 100
  • 導入バージョン: v3.0

resource_group​

  • 説明: このセッションの指定されたリソースグループ
  • デフォルト: ""
  • データタイプ: String
  • 導入バージョン: 3.2.0

runtime_filter_on_exchange_node​

  • 説明: GRF が Exchange オペレーターを越えて下位レベルのオペレーターにプッシュダウンされた後、Exchange ノードに配置されるかどうか。デフォルト値は false で、GRF は Exchange オペレーターを越えて下位レベルのオペレーターにプッシュダウンされた後、Exchange ノードに配置されません。これにより、GRF の繰り返し使用が防止され、計算時間が短縮されます。

    ただし、GRF の配信は「最善を尽くす」プロセスです。下位レベルのオペレーターが GRF を受け取れない場合、GRF が Exchange ノードに配置されていないと、データがフィルタリングされず、フィルタパフォーマンスが損なわれます。true は、GRF が Exchange オペレーターを越えて下位レベルのオペレーターにプッシュダウンされた後でも、Exchange ノードに配置されることを意味します。

  • デフォルト: false

runtime_join_filter_push_down_limit​

  • 説明: Bloom フィルターローカル RF が生成されるハッシュテーブルの最大行数。ローカル RF は、この値を超えると生成されません。この変数は、過度に長いローカル RF の生成を防ぎます。
  • デフォルト: 1024000
  • データ型: Int

runtime_profile_report_interval​

  • 説明: ランタイムプロファイルが報告される時間間隔。
  • デフォルト: 10
  • 単位: 秒
  • データ型: Int
  • 導入バージョン: v3.1.0

scan_olap_partition_num_limit​

  • 説明: 実行プランで単一のテーブルに対してスキャンされるパーティションの数。
  • デフォルト: 0（制限なし）
  • 導入バージョン: v3.3.9

allow_lake_without_partition_filter​

  • 説明: レイクテーブル（Hive、Iceberg、Delta Lake、Paimon など）に対してパーティションフィルターなしのクエリを許可するかどうか。false に設定すると、有効なパーティションフィルターを含まないクエリは拒否され、意図しないフルテーブルスキャンを防止します。
  • スコープ: セッション
  • デフォルト: true
  • タイプ: Boolean
  • エイリアス: allow_hive_without_partition_filter

scan_lake_partition_num_limit​

  • 説明: 単一のレイクテーブル（Hive、Iceberg、Delta Lake、Paimon など）に対してスキャンできるパーティションの最大数。0 に設定すると制限なし。上限を超えるとクエリはエラーを返します。なお、増分的にスプリットを列挙するカタログタイプ（Iceberg、Delta Lake）では、制限チェックはスキャンレンジのディスパッチ時に行われ、クエリが即座に拒否されるのではなく、実行途中で失敗する場合があります。
  • スコープ: セッション
  • デフォルト: 0（制限なし）
  • タイプ: Int
  • エイリアス: scan_hive_partition_num_limit

skip_local_disk_cache​

  • 説明: FE がスキャンレンジを構築するときに、各タブレットの内部スキャンレンジに skip_disk_cache をマークするよう指示するセッションフラグです。true に設定すると、OlapScanNode.addScanRangeLocations() は作成された TInternalScanRange オブジェクトに対して internalRange.setSkip_disk_cache(true) を設定するため、下流の BE スキャンノードはそのスキャンでローカルディスクキャッシュをバイパスするよう指示されます。この設定はセッション単位で適用され、プラン／スキャンレンジ構築時に評価されます。ページキャッシュスキップの制御には skip_page_cache と組み合わせて使用し、データキャッシュ関連の変数（enable_scan_datacache / enable_populate_datacache）と併せて適切に利用してください。
  • スコープ: セッション
  • デフォルト: false
  • タイプ: boolean
  • 導入バージョン: v3.3.9, v3.4.0, v3.5.0

spill_encode_level​

  • スコープ: セッション
  • 説明: オペレータのスピルファイルに適用されるエンコード／圧縮の振る舞いを制御します。整数はビットフラグレベルで、意味は transmission_encode_level と同様です:
    • bit 1 (値 1) — 適応エンコーディングを有効にする;
    • bit 2 (値 2) — 整数のような列を streamvbyte でエンコードする;
    • bit 4 (値 4) — バイナリ／文字列列を LZ4 で圧縮する。 関連する transmission_encode_level のコメントからの例の意味: 7 は数値と文字列の適応エンコーディングを有効にし、6 は数値と文字列のエンコードを強制します。この値を変更するとスピル時の CPU とディスク I/O のトレードオフが調整されます（エンコードレベルが高いほど CPU 負荷は増えるがスピルサイズ／I/O は減少します）。 SessionVariable.java のセッション変数として注釈された SPILL_ENCODE_LEVEL（getter getSpillEncodeLevel()）として実装されており、spill_mem_table_size のような他のスピル調整可能項目の近くに文書化されています。
  • デフォルト: 7
  • タイプ: int
  • 導入バージョン: v3.2.0

spill_mode (3.0 以降)​

中間結果のスピルの実行モード。有効な値:

  • auto: メモリ使用量のしきい値に達したときにスピルが自動的にトリガーされます。
  • force: StarRocks はメモリ使用量に関係なく、すべての関連オペレーターに対してスピルを強制的に実行します。

この変数は、変数 enable_spill が true に設定されている場合にのみ有効です。

spill_storage_volume​

  • 説明: スピルをトリガーしたクエリの中間結果を保存するために使用するストレージボリューム。
  • デフォルト: 空の文字列
  • 導入バージョン: v3.3.0

sql_dialect​

  • 説明: 使用される SQL ダイアレクト。たとえば、set sql_dialect = 'trino'; コマンドを実行して SQL ダイアレクトを Trino に設定すると、クエリで Trino 固有の SQL 構文と関数を使用できます。

    注意

    StarRocks を Trino ダイアレクトで使用するように設定した後、クエリ内の識別子はデフォルトで大文字小文字を区別しません。したがって、データベースやテーブルの作成時に名前を小文字で指定する必要があります。データベースやテーブル名を大文字で指定すると、これらのデータベースやテーブルに対するクエリが失敗します。

  • データ型: StarRocks

  • 導入バージョン: v3.0

sql_mode​

特定の SQL ダイアレクトに対応する SQL モードを指定するために使用されます。有効な値には以下が含まれます：

  • PIPES_AS_CONCAT: パイプ記号 | を使用して文字列を連結します。例：select 'hello ' || 'world'。
  • ONLY_FULL_GROUP_BY（デフォルト）: SELECT リストには GROUP BY 列または集計関数のみを含めることができます。
  • ALLOW_THROW_EXCEPTION: 型変換が失敗した場合に NULL の代わりにエラーを返します。
  • FORBID_INVALID_DATE: 無効な日付を禁止します。
  • MODE_DOUBLE_LITERAL: 浮動小数点型を DECIMAL ではなく DOUBLE として解釈します。
  • SORT_NULLS_LAST: ソート後に NULL 値を最後に配置します。
  • ERROR_IF_OVERFLOW: 算術オーバーフローが発生した場合に NULL の代わりにエラーを返します。現在、このオプションは DECIMAL データ型にのみ対応しています。
  • GROUP_CONCAT_LEGACY: v2.5 およびそれ以前の group_concat 構文を使用します。このオプションは v3.0.9 および v3.1.6 からサポートされています。
  • FORBID_INVALID_IMPLICIT_CAST: プラン時に Trino 風の厳格な型チェックを有効にします。暗黙的に許可されるのは同一型ファミリ内の拡張（widening）変換のみです（例: TINYINT→INT→BIGINT→DECIMAL→DOUBLE、DATE→DATETIME）。VARCHAR/CHAR 間の暗黙的キャストは宣言された長さを問わず許可されます。型ファミリをまたぐキャスト（string↔numeric、string↔date、numeric↔date、boolean と他の型など）や数値の縮小（narrowing）キャスト（BIGINT→INT、DOUBLE→FLOAT など）はセマンティックエラーとして拒否されます。これらの変換が必要な場合は、明示的な CAST を使用してください。
  • STRUCT_CAST_BY_NAME: STRUCT 型間のキャストにおいて、デフォルトの位置ベースのマッチングではなく、名前ベースのフィールドマッチングを有効にします。このモードが有効になっている場合、ソース構造体のフィールドは、宣言順序に関係なく、フィールド名（大文字小文字を区別しない）に基づいてターゲット構造体のフィールドと照合されます。ソース側には存在するがターゲット側には存在しないフィールドは無視され、ターゲット側には存在するがソース側には存在しないフィールドは NULL で埋められます。このモードは、FE型の解決（UNION ALL における共通のスーパータイプの計算やキャスト可能性のチェック）と、BEキャストの評価（CastStructExpr における実行時のフィールドの順序変更）の両方に影響します。これは、分岐間でフィールドの定義順序が異なるSTRUCT列に対して UNION ALL を実行する場合に特に有用です。

1 つの SQL モードのみを設定できます。例：

set sql_mode = 'PIPES_AS_CONCAT';

または、複数のモードを一度に設定することもできます。例：

set sql_mode = 'PIPES_AS_CONCAT,ERROR_IF_OVERFLOW,GROUP_CONCAT_LEGACY';

sql_safe_updates​

MySQL クライアント互換性のために使用されます。実際の用途はありません。

sql_select_limit​

  • 説明: クエリによって返される最大行数を制限するために使用されます。これにより、クエリが大量のデータを返すことによって発生するメモリ不足やネットワーク混雑などの問題を防ぐことができます。
  • デフォルト: 無制限
  • データ型: Long

storage_engine​

StarRocks がサポートするエンジンの種類：

  • olap（デフォルト）: StarRocks システム所有のエンジン。
  • mysql: MySQL 外部テーブル。
  • broker: ブローカープログラムを介して外部テーブルにアクセス。
  • elasticsearch または es: Elasticsearch 外部テーブル。
  • hive: Hive 外部テーブル。
  • iceberg: Iceberg 外部テーブル（v2.1 からサポート）。
  • hudi: Hudi 外部テーブル（v2.2 からサポート）。
  • jdbc: JDBC 互換データベースの外部テーブル（v2.3 からサポート）。

streaming_preaggregation_mode​

GROUP BY の最初のフェーズの事前集計モードを指定するために使用されます。最初のフェーズでの事前集計効果が満足できない場合、ストリーミングモードを使用できます。これは、データをストリーミング先に送信する前に簡単なデータシリアル化を行います。有効な値：

  • auto: システムは最初にローカル事前集計を試みます。効果が満足できない場合、ストリーミングモードに切り替えます。これはデフォルト値です。
  • force_preaggregation: システムは直接ローカル事前集計を行います。
  • force_streaming: システムは直接ストリーミングを行います。

system_time_zone​

現在のシステムのタイムゾーンを表示するために使用されます。変更できません。

lake_multi_node_tablet_write_mode​

  • 説明: 共有データモードでのみ有効です。ロードが 1 つの Tablet の書き込みを複数のコンピュートノードに分散できるかどうかを制御します。分散しない場合、すべての行はその Tablet が割り当てられた単一のノードへ送られます。3 つの値があります:
    • off — 決して分散しません。本機能が導入される前の動作です。
    • auto (デフォルト) — range bucket 分布のテーブルで、そのパーティションの Tablet 数が、このロードに見合う書き込みノード数 (lake_multi_node_write_bytes_per_node を参照) より少ない場合に分散します。pre-split はステートメントの計画前に実行され、その完了を待ってから進むため、ここで読まれる Tablet 数は pre-split の結果です: 十分に分割できていれば auto は介入せず、スキップされた場合や待機がタイムアウトして現在見えているレイアウトのままロードが続行された場合は auto が有効になります。すべての key タイプに適用されます: 同じ key を持つ行は key 列のハッシュでルーティングされるため 1 つのノードに到達し、結果はどのノードがどの行を書いたかに依存しません。ハッシュバケットのテーブルは、バケット数を増やせばクラスタを埋められるため対象外です。
    • force — 残りの前提条件が満たされる限り分散します。ハッシュバケット分布も含みます。auto が引き受けないテーブルでも分散させたい場合に使用します。
  • モードにかかわらず、次の条件も必要です: file_bundling が有効なクラウドネイティブテーブル、combined txn log を使用するトランザクション、およびパーティションの Tablet 数が、このロードが実際に分散されるノード数より少ないこと。その幅は次の 3 つのうち最小のものです: ロードのサイズから求めたノード数 (lake_multi_node_write_bytes_per_node を参照)、lake_multi_node_write_max_nodes、稼働中のコンピュートノード数。すでにその数の Tablet を持つパーティションは force を指定しても単一ノードの書き込みのままです。6 ノードの Warehouse で Tablet が 5 つある場合、ロードのサイズが 3 ノード分の価値しかなければ分散しません。Stream Load と Routine Load は対象外です。どちらもプラン作成時にサイズが分からず、そこで未知のサイズを大きなサイズとして扱うと、最も小さく最も頻繁なバッチが最も広く分散されてしまうためです。部分更新 (行モードと列モード)、条件付き更新、自動インクリメント列を省略したロード、スキーマ変更中のロードはいずれもサポートされます。
  • ロードの実行中に自動パーティション機能が作成したパーティションも分散されます。そのパーティションはプランに含まれていないため、Tablet はその後 create-partition RPC を通じてロードへ渡されます。プラン作成時にロードが決定したものと同じノード数に分散され、パーティション作成時点で稼働しているコンピュートノードから選択されます。長時間実行されるロードでは、プラン作成時のノードリストより長く実行されることがあります。このようなパーティションは通常 1 つの Tablet から始まります。分割に必要なデータ境界がまだ検出されていないためであり、まさにこの設定の対象となる形です。
  • ロードの実行中に自動バケット（bucket_size）が追加したサブパーティションも同様に分散されます。自動バケットは RANDOM 分散にのみ適用されるため、これが有効になるのは force の場合だけです。
  • デフォルト値: auto
  • 型: String
  • スコープ: Session
  • 導入バージョン: v26.2

lake_multi_node_write_max_nodes​

  • 説明: 1 つの Tablet を並列に書き込めるコンピュートノード数の上限です。Tablet のノードリストにある各ノードはそれぞれ自身の delta writer を開き、自身の segment を生成します。そのため非常に広い Warehouse では、通常規模のロードがその数だけ小さな segment に分割されてしまいます。この上限を超えたノードも自身の sink インスタンスは実行し、その行はネットワーク経由でリスト内のノードへ送られます。これは本機能が導入される前の動作であり、上限は局所性を犠牲にするだけで正しさには影響しません。これは上限であって並列度そのものではありません: 実際に使用される値は、この変数、ロードの推定サイズから算出されたノード数 (lake_multi_node_write_bytes_per_node)、稼働中コンピュートノード数の最小値です。0 以下に設定すると上限なしになります。
  • デフォルト値: 6
  • 型: Int
  • スコープ: Session
  • 導入バージョン: v26.2

lake_multi_node_write_bytes_per_node​

  • 説明: 共有データモードでのみ有効で、lake_multi_node_tablet_write_mode が有効な場合にのみ作用します。Tablet の書き込み集合に次のノードを追加する前に、1 つのコンピュートノードへ割り当てるロードのバイト数です。ノード数はロードの推定サイズをこの値で割ったもので (整数除算のため、1 ノード分がまるごと確保できて初めてノードが追加されます)、最終的に使用される並列度は、その値、セッション変数 lake_multi_node_write_max_nodes、および稼働中コンピュートノード数の最小値になります。例えば 10 GB のロードはデフォルトの 2 GB で 5 ノードとなり、3 ノードの Warehouse ではさらに 3 に制限されます。書き込みの分散は無償ではありません: Tablet のノードリストにある各ノードはそれぞれ自身の segment を書き出し、自身の部分トランザクションログを生成します。さらに open/close は、そのノードが最終的に行を保持するかどうかにかかわらずリスト内のすべてのノードに到達します。したがって小さなロードを広く分散させると、ノードごとに segment とログが余分に増えるだけで得るものはわずかです。サイズは、INSERT ではオプティマイザの推定値から、Broker Load では解決済みのファイルリストから取得します。この 2 つの経路でどちらも利用できない場合、ノード数は lake_multi_node_write_max_nodes のみに委ねられます。Stream Load と Routine Load は例外で、そもそも分散しません。これらの経路でサイズが不明であることは、推定できなかった大きなロードではなく、マイクロバッチであることを意味するからです。サイズが不明であることは、サイズが小さいことを意味しないためです。0 に設定すると、サイズに基づく算出を無効にします。
  • デフォルト値: 2147483648 (2 GB)
  • 単位: バイト
  • 型: Long
  • スコープ: Session
  • 導入バージョン: v26.2

time_zone​

現在のセッションのタイムゾーンを設定するために使用されます。タイムゾーンは、特定の時間関数の結果に影響を与える可能性があります。

transaction_read_only​

  • 説明: MySQL 5.8 互換性のために使用されます。エイリアスは tx_read_only です。この変数はトランザクションのアクセスモードを指定します。ON は読み取り専用を示し、OFF は読み取りおよび書き込み可能を示します。
  • デフォルト: OFF
  • 導入バージョン: v2.5.18, v3.0.9, v3.1.7

tx_isolation​

MySQL クライアント互換性のために使用されます。実際の用途はありません。エイリアスは transaction_isolation です。

tx_visible_wait_timeout​

  • 説明: コミット済みトランザクションが可視（公開）になるまでサーバが待機する時間（秒単位）を制御するセッションスコープのタイムアウトです。StmtExecutor および TransactionStmtExecutor のコミットフローで使用されるミリ秒単位の publish 待機時間はこの値に1000を掛けて算出されます。可視待機が期限切れになると、トランザクションは COMMITTED と扱われますがまだ VISIBLE ではないと見なされます。マテリアライズドビューのリフレッシュロジック（MVTaskRunProcessor）は、可視性を事実上無期限に待つために一時的にこの変数を Long.MAX_VALUE / 1000 に設定し、リフレッシュ後に元の値を復元します。enable_sync_publish が有効な場合、この変数は無視され、publish 待機はジョブのデッドラインから派生されます。
  • スコープ: Session
  • デフォルト: 10
  • データ型: long
  • 導入バージョン: v3.2.0

version (global)​

クライアントに返される MySQL サーバーバージョン。値は FE パラメータ mysql_server_version と同じです。

version_comment (global)​

StarRocks のバージョン。変更できません。

wait_timeout​

  • 説明: サーバーが非対話型接続でアクティビティを待機する秒数。この時間が経過してもクライアントが StarRocks と対話しない場合、StarRocks は接続を積極的に閉じます。
  • デフォルト: 28800（8 時間）。
  • 単位: 秒
  • データ型: Int

enable_jdbc_agg_push_down​

  • スコープ: Session
  • 説明: オプティマイザが JDBC catalog テーブル上の対象集計操作を JDBC データソースへプッシュダウンできるかどうかを制御します。true に設定すると、システムはサポートされる集計式、GROUP BY キー、および HAVING 述語を JDBC scan SQL の一部としてリモートデータベースへ送信できます。関連するセッション変数も有効な場合、このプッシュダウンは JDBC join および project プッシュダウンと組み合わせることができます。false に設定すると、集計はシステム側で実行されます。
  • デフォルト: true
  • データ型: boolean
  • 導入バージョン: v4.1

enable_jdbc_join_push_down​

  • スコープ: Session
  • 説明: オプティマイザが JDBC catalog テーブル上の対象 join を JDBC データソースへプッシュダウンできるかどうかを制御します。true に設定すると、システムは互換性のある JDBC scan から、サポートされる join、プッシュダウン可能な述語、および必要な出力列を 1 つのリモート SQL クエリにマージできます。false に設定すると、join はシステム側で実行されます。
  • デフォルト: true
  • データ型: boolean
  • 導入バージョン: v4.1

enable_jdbc_project_push_down​

  • スコープ: Session
  • 説明: オプティマイザが JDBC catalog テーブル上の対象 projection 式を JDBC データソースへプッシュダウンできるかどうかを制御します。true に設定すると、システムはサポートされる列 projection および式 projection をリモート JDBC SELECT リストに含めることができます。関連するセッション変数も有効な場合、このプッシュダウンは JDBC join および aggregate プッシュダウンと組み合わせることができます。false に設定すると、projection 式はシステム側で計算されます。
  • デフォルト: true
  • データ型: boolean
  • 導入バージョン: v4.1

jdbc_predicate_pushdown_max_in_list_size​

  • スコープ: Session
  • 説明: システムが JDBC データソースへプッシュダウンできる IN 述語リスト内のリテラル値の最大数。この変数は JDBC scan の述語プッシュダウンおよび HAVING プッシュダウンに適用されます。-1 に設定するとシステム側の制限はありません。0 に設定すると IN 述語のプッシュダウンを無効にします。正の整数 N に設定すると、値の数が N 以下の IN リストのみをプッシュダウンします。Oracle の IN リスト制限など、リモートデータベースの制限に合わせてこの値を調整できます。
  • デフォルト: -1
  • データ型: int
  • 導入バージョン: v4.1

warehouse​

  • 説明: 現在のセッションで使用するウェアハウスを指定します。
  • デフォルト: "default_warehouse"
  • 単位: -
  • データ型: String