Skip to main content
ClickHouse Cloud でのクエリこのシステムテーブルのデータは、ClickHouse Cloud の各ノードにローカルに保持されています。したがって、すべてのデータを完全に把握するには、clusterAllReplicas 関数を使用する必要があります。詳細については、こちらを参照してください。

説明

実行されたクエリに関するメタデータと統計情報 (開始時刻、所要時間、エラーメッセージ、リソース使用量、その他の実行詳細など) を保存します。クエリの結果は保存しません。 クエリのログに関する設定は、サーバー設定の query_log セクションで変更できます。 log_queries = 0 を設定すると、クエリのログを無効にできます。問題の解決にはこのテーブルの情報が重要であるため、ログを無効にすることは推奨されません。 データのフラッシュ間隔は、サーバー設定の query_log セクションにある flush_interval_milliseconds パラメータで設定します。強制的にフラッシュするには、SYSTEM FLUSH LOGS クエリを使用します。 ClickHouse はテーブルからデータを自動的に削除しません。詳しくは Introduction を参照してください。 system.query_log テーブルには、2 種類のクエリが記録されます。
  1. 初期 (最上位) クエリ。
  2. 分散実行用のクエリやビュー評価などの内部サブクエリを含む、他のクエリによって開始された子クエリ。これらのクエリでは、元の初期クエリに関する情報が initial_* カラムに表示されます。
デフォルトで初期クエリをフィルタリングする 通常、system.query_log をクエリする際は常に is_initial_query = 1 を追加してください。これにより子クエリが除外され、個々の処理ステップが初期クエリとは別にカウントされなくなります。このフィルターは、クエリがクライアントによって送信されたことを意味するものではありません。サーバー内部の処理も初期クエリになる場合があるためです。 ID を保持する子クエリとともに初期クエリをトレースする必要がある場合は、代わりに initial_query_id を使用します。初期クエリでは initial_query_id と query_id の値が同じですが、同じチェーン内の子クエリは初期クエリの initial_query_id を保持し、それぞれ独自の query_id を持ちます。初期クエリによって生成されるすべての処理がこのように相関付けられるわけではありません。リモート QueryRunner の送出と同様に、サーバーによって送出された処理は、新しい initial_query_id を持つ新しい初期クエリチェーンを開始する場合があります。
相関付けられた子クエリが他のノードで実行される可能性がある場合は、たとえば clusterAllReplicas を使用して、すべてのノードで system.query_log をクエリします。 各クエリは、クエリのステータス (type カラムを参照) に応じて、query_log テーブルに 1 行または 2 行を作成します。
  1. クエリの実行が成功した場合は、QueryStart 型と QueryFinish 型の 2 行が作成されます。
  2. クエリ処理中にエラーが発生した場合は、QueryStart 型と ExceptionWhileProcessing 型の 2 つのイベントが作成されます。
  3. クエリの開始前にエラーが発生した場合は、ExceptionBeforeStart 型の単一イベントが作成されます。
log_queries_probability 設定を使用すると、query_log テーブルに記録されるクエリ数を減らせます。 log_formatted_queries 設定を使用すると、整形済みクエリを formatted_query カラムに記録できます。 このテーブルは、いつでも安全に TRUNCATE または削除できます。

カラム

  • hostname (LowCardinality(String)) — クエリを実行しているサーバーのホスト名。
  • clickhouse_version (LowCardinality(String)) — この行を生成した ClickHouse サーバーのバージョン。
  • system_processor (LowCardinality(String)) — この行を生成した ClickHouse サーバーの CPU アーキテクチャ。
  • type (Enum8(‘QueryStart’ = 1, ‘QueryFinish’ = 2, ‘ExceptionBeforeStart’ = 3, ‘ExceptionWhileProcessing’ = 4)) — クエリ実行時に発生したイベントの種類。値: QueryStart — クエリ実行の正常な開始、QueryFinish — クエリ実行の正常な終了、ExceptionBeforeStart — クエリ実行開始前の例外、ExceptionWhileProcessing — クエリ実行中の例外。
  • event_date (Date) — クエリの開始日付。
  • event_time (DateTime) — クエリの開始時刻。
  • event_time_microseconds (DateTime64(6)) — マイクロ秒精度でのクエリ開始時刻。
  • query_start_time (DateTime) — クエリ実行の開始時刻。
  • query_start_time_microseconds (DateTime64(6)) — マイクロ秒精度で記録されるクエリ実行の開始時刻。
  • query_duration_ms (UInt64) — クエリの実行時間 (ミリ秒) 。
  • read_rows (UInt64) — クエリに関与したすべてのテーブルおよびテーブル関数から読み取られた行の総数です。通常のサブクエリに加え、IN および JOIN のサブクエリも含まれます。分散クエリでは、read_rows にはすべてのレプリカで読み取られた行の総数が含まれます。各レプリカは自身の read_rows の値を送信し、クエリのサーバー側のイニシエーターが、受信したすべての値とローカルの値を集計します。cache の容量はこの値には影響しません。
  • read_bytes (UInt64) — クエリで使用されたすべてのテーブルおよびテーブル関数から読み取られた合計バイト数です。通常のサブクエリに加え、IN および JOIN 用のサブクエリも含まれます。分散クエリでは、read_bytes にはすべてのレプリカで読み取られた行数の合計が含まれます。各レプリカは自身の read_bytes の値を送信し、クエリのイニシエーターであるサーバーが、受信したすべての値とローカルの値を集計します。cache のサイズはこの値に影響しません。
  • written_rows (UInt64) — パイプラインによってトリガーされた下流の insert (アタッチされた materialized view など) によって書き込まれた行も含めた、クエリによる書き込み行数。同期 insert の場合、これらの下流の行は query_kind = Insert のエントリに記録されます。非同期挿入の場合、それらは query_kind = AsyncInsertFlush のエントリに記録され、クライアント向けの Insert エントリにはクライアントから受け付けた行のみが記録されます。行を書き込まないクエリでは 0 です。
  • written_bytes (UInt64) — パイプラインによってトリガーされた下流の insert (アタッチされた materialized view など) によって書き込まれたバイトも含めた、クエリによる書き込みバイト数 (非圧縮)。同期 insert の場合、これらの下流のバイトは query_kind = Insert のエントリに記録されます。非同期挿入の場合、それらは query_kind = AsyncInsertFlush のエントリに記録され、クライアント向けの Insert エントリにはクライアントから受け付けたバイトのみが記録されます。データを書き込まないクエリでは 0 です。
  • result_rows (UInt64) — SELECT クエリの結果の行数、または insert によって書き込まれた行数。同期 insert の場合、これには query_kind = Insert のエントリに記録される、パイプラインによってトリガーされた下流の insert (アタッチされた materialized view など) によって書き込まれた行が含まれます。非同期挿入の場合、それらの下流の行は query_kind = AsyncInsertFlush のエントリに記録され、クライアント向けの Insert エントリにはクライアントから受け付けた行のみが記録されます。
  • result_bytes (UInt64) — クエリ結果の保存に使用されるRAMの量 (バイト単位) 。
  • memory_usage (UInt64) — クエリのメモリ使用量。
  • current_database (LowCardinality(String)) — 現在のデータベース名。
  • query (String) — クエリ文字列。
  • formatted_query (String) — 整形済みのクエリ文字列。
  • normalized_query_hash (UInt64) — リテラル値だけが異なるクエリでは同一となる数値のハッシュ値。
  • query_kind (LowCardinality(String)) — クエリの種別。
  • databases (Array(LowCardinality(String))) — クエリに含まれるデータベース名。
  • tables (Array(LowCardinality(String))) — クエリに含まれるテーブル名。
  • columns (Array(LowCardinality(String))) — クエリ内に含まれるカラム名。
  • partitions (Array(LowCardinality(String))) — クエリに含まれるパーティション名。
  • projections (Array(LowCardinality(String))) — クエリ実行時に使用されたプロジェクションの名前。
  • views (Array(LowCardinality(String))) — クエリに含まれる (マテリアライズドビューまたはライブビュー) の名前。
  • exception_code (Int32) — 例外コード。
  • exception (String) — 例外メッセージ。
  • stack_trace (String) — スタックトレース。クエリが正常に完了した場合は、空文字列です。
  • is_initial_query (UInt8) — クエリが初期クエリかどうか。設定可能な値: 1 — 初期 (最上位) クエリ、0 — 分散クエリ実行用のクエリおよび内部サブクエリを含む、別のクエリによって開始された子クエリ。
  • connection_address (IPv6) — 接続元のクライアント IP アドレス。プロキシ経由で接続している場合は、プロキシのアドレスになります。
  • connection_port (UInt16) — 接続元のクライアントポートです。プロキシ経由で接続している場合は、プロキシのポートになります。
  • user (LowCardinality(String)) — 現在のクエリを実行したユーザー名。
  • query_id (String) — クエリの識別子。
  • address (IPv6) — クエリの実行に使用された IP アドレス。プロキシ経由で接続され、auth_use_forwarded_address が設定されている場合、これはプロキシではなくクライアントのアドレスになります。
  • port (UInt16) — クエリの実行に使用されたクライアントのポート。プロキシ経由で接続しており、auth_use_forwarded_address が設定されている場合、これはプロキシではなくクライアント側のポートになります。
  • initial_user (LowCardinality(String)) — 同じクエリチェーン内の初期クエリを実行したユーザー名。
  • initial_query_id (String) — 同じクエリチェーン内の初期クエリの ID。
  • initial_address (IPv6) — 同じクエリチェーン内の初期クエリが開始された送信元 IP アドレス。
  • initial_port (UInt16) — 同じクエリチェーン内の初期クエリが開始されたクライアントポート。
  • initial_query_start_time (DateTime) — 同じクエリチェーン内の初期クエリの開始時刻。
  • initial_query_start_time_microseconds (DateTime64(6)) — マイクロ秒精度で記録される、同じクエリチェーン内の初期クエリの開始時刻。
  • authenticated_user (LowCardinality(String)) — セッション内で認証されたユーザー名。
  • interface (Enum8(‘Unknown’ = 0, ‘TCP’ = 1, ‘HTTP’ = 2, ‘gRPC’ = 3, ‘MySQL’ = 4, ‘PostgreSQL’ = 5, ‘Local’ = 6, ‘TCP_Interserver’ = 7, ‘Prometheus’ = 8, ‘Background’ = 9, ‘ArrowFlight’ = 10)) — クライアントから報告された、クエリの開始元となったインターフェイス。報告されたインターフェイスがこのサーバーの認識できるものでない場合は Unknown になります。
  • is_secure (UInt8) — クエリがセキュアなインターフェイス経由で実行されたかどうかを示すフラグ
  • os_user (LowCardinality(String)) — clickhouse-client を実行しているオペレーティングシステムのユーザー名。
  • client_hostname (LowCardinality(String)) — clickhouse-client または別の TCP クライアントが実行されているクライアントマシンのホスト名。
  • client_name (LowCardinality(String)) — clickhouse-client または他の TCP クライアントの名前。
  • client_agent (LowCardinality(String)) — クライアントを呼び出した AI コーディングエージェント (例: claude-code、cursor)。環境変数から検出されます。エージェントが検出されなかった場合は空です。
  • client_revision (UInt32) — clickhouse-client または他の TCP クライアントのリビジョン。
  • client_version_major (UInt32) — clickhouse-client またはその他の TCP クライアントのメジャーバージョン。
  • client_version_minor (UInt32) — clickhouse-client またはその他の TCP クライアントのマイナーバージョン。
  • client_version_patch (UInt32) — clickhouse-client または他の TCP クライアントのバージョンにおけるパッチ部分。
  • script_query_number (UInt32) — clickhouse-client で、複数のクエリを含むスクリプト内のクエリ番号。
  • script_line_number (UInt32) — clickhouse-client において、複数のクエリを含むスクリプトでクエリが開始される行番号です。
  • http_method (Enum8(‘UNKNOWN’ = 0, ‘GET’ = 1, ‘POST’ = 2, ‘OPTIONS’ = 3, ‘PUT’ = 4, ‘DELETE’ = 5, ‘HEAD’ = 6)) — クエリの実行を開始した HTTP メソッド。クエリが HTTP 経由で到達しなかった場合、または報告されたメソッドがこのサーバーの認識できるものでない場合は UNKNOWN になります。
  • http_user_agent (LowCardinality(String)) — HTTPクエリで送信されるHTTPヘッダー UserAgent。
  • http_referer (String) — HTTPクエリで渡されるHTTPヘッダーのReferer (クエリを行うページの絶対アドレスまたは部分的なアドレスを含みます) 。
  • forwarded_for (String) — HTTPクエリで渡される X-Forwarded-For HTTPヘッダー。
  • quota_key (String) — quotas 設定で指定するクォータキー (keyed を参照) 。
  • distributed_depth (UInt64) — クエリがサーバー間で何回転送されたか。
  • revision (UInt32) — ClickHouseのリビジョン番号。
  • http_handler_name (String) — クエリを呼び出した SQL 定義の HTTP ハンドラー (CREATE HANDLER) の名前。このようなハンドラーを介してクエリが呼び出されなかった場合は空です。
  • http_request_url (String) — クエリを呼び出した HTTP リクエストパス (クエリ文字列を除く)。機密性の高いリクエストパラメータが永続化されないよう、クエリ文字列は省略されます。HTTP 以外のクエリでは空です。
  • log_comment (String) — ログコメント。max_query_size を超えない任意の文字列を設定できます。定義されていない場合は空文字列です。
  • thread_ids (Array(UInt64)) — クエリの実行に関与しているスレッド ID。これらのスレッドが同時に実行されていたとは限りません。
  • peak_threads_usage (UInt64) — クエリの実行時に同時に使用されるスレッド数の最大値。
  • ProfileEvents (Map(LowCardinality(String), UInt64)) — さまざまなメトリクスを計測する ProfileEvents です。これらの説明は system.events テーブルにあります
  • Settings (Map(LowCardinality(String), LowCardinality(String))) — クライアントがクエリを実行したときに変更された設定。設定の変更を記録するには、log_query_settings パラメータを 1 に設定します。
  • used_aggregate_functions (Array(LowCardinality(String))) — クエリの実行中に使用された集約関数の正式名。
  • used_aggregate_function_combinators (Array(LowCardinality(String))) — クエリ実行時に使用された集約関数コンビネータの正準名。
  • used_database_engines (Array(LowCardinality(String))) — クエリの実行中に使用されたデータベースエンジンの正式名称。
  • used_data_type_families (Array(LowCardinality(String))) — クエリ実行時に使用されたデータ型ファミリーの標準名。
  • used_dictionaries (Array(LowCardinality(String))) — クエリ実行時に使用された辞書の正規名。
  • used_formats (Array(LowCardinality(String))) — クエリ実行時に使用されたフォーマットの正式名。
  • used_functions (Array(LowCardinality(String))) — クエリの実行中に使用された関数の正式名。
  • used_storages (Array(LowCardinality(String))) — クエリの実行時に使用されたストレージの正式名称。
  • used_table_functions (Array(LowCardinality(String))) — クエリの実行時に使用されたテーブル関数の正規名。
  • used_executable_user_defined_functions (Array(LowCardinality(String))) — クエリ実行時に使用された実行可能なユーザー定義関数の正規名。
  • used_sql_user_defined_functions (Array(LowCardinality(String))) — クエリ実行中に使用された SQL ユーザー定義関数の正規名。
  • used_row_policies (Array(LowCardinality(String))) — クエリ実行中に使用された行ポリシー名の一覧。
  • used_privileges (Array(LowCardinality(String))) — クエリ実行時に正常にチェックされた権限。
  • missing_privileges (Array(LowCardinality(String))) — クエリ実行時に不足している権限。
  • used_number_of_joins (UInt64) — このクエリで実行された物理的な結合の数。パイプラインの構築時に収集されるため、クエリテキスト内の JOIN 句の数ではなく、すべての最適化が適用された後に残った結合の数を反映します。結合はネストの深さに関係なくカウントされます。サブクエリ、共通テーブル式、ビュー、ビューのビュー、および INSERT によってトリガーされた materialized view の SELECT は、いずれも送信されたクエリの行に集計されます。そのため、クエリ自体のテキストに JOIN がまったく含まれていなくても、この値が 0 以外になることがあります。EXPLAIN PIPELINE のように、パイプラインを構築するだけで実行しないクエリでは、説明対象のクエリの結合が報告されます。1 つのクエリの実行中に、一部のパイプラインは複数回組み立てられます。materialized view の SELECT は、それをトリガーする INSERT のブロックごと、および insert ストリームごとに組み立てられます。再帰 CTE の再帰メンバーは反復ごとに組み立てられ、ループのリレーションは再開されるたびに組み立て直されます。それでも、このようなパイプラインの結合は 1 回だけカウントされます。したがって、この数値はパイプラインが組み立てられた回数ではなく、クエリそのものを表します。
  • used_join_algorithms (Array(LowCardinality(String))) — used_number_of_joins でカウントされた結合のアルゴリズム: ‘HASH’、‘PARALLEL_HASH’、‘GRACE_HASH’、‘PARTIAL_MERGE’、‘FULL_SORTING_MERGE’、‘PARALLEL_FULL_SORTING_MERGE’、‘IE_JOIN’、‘DIRECT’、‘PASTE’、‘CONSTANT’。ソートおよび重複排除されているため、複数の結合で共通するアルゴリズムは 1 回だけ現れます。これは join_algorithm 設定で許可されているアルゴリズムではなく、各結合の実行に実際に選択されたアルゴリズムです。実行途中でアルゴリズムが別のものに切り替わることがあり、その場合は両方が報告されます。
  • used_join_kinds (Array(LowCardinality(String))) — used_number_of_joins でカウントされた結合の種類。結合ごとに 1 つの要素を持つため、複数の結合で共通する種類は複数回現れます。要素は実行順ではなく、ソートされた順に並びます。各種類は実際に実行されたものであり、クエリテキストとは異なる場合があります。これは、オプティマイザが結合の左右を入れ替えて実行し、その結果 LEFT が RIGHT に変わることがあるためです。
  • used_join_strictness (Array(LowCardinality(String))) — used_number_of_joins でカウントされた結合の厳密性。結合ごとに 1 つの要素を持ち、used_join_kinds と同じ順序で並びます。つまり、両方の配列で同じインデックスの要素は同じ結合を表します。
  • spilled_to_disk (Array(LowCardinality(String))) — クエリ実行中にディスク上の一時ファイルへデータを書き込んだ (外部メモリで処理した) 演算子。ソートおよび重複排除されています。空の配列は、クエリがすべてメモリ内で実行されたことを意味します。
  • transaction_id (Tuple(UInt64, UInt64, UUID, Int64)) — このクエリが属するトランザクションの識別子。
  • query_cache_usage (Enum8(‘Unknown’ = 0, ‘None’ = 1, ‘Write’ = 2, ‘Read’ = 3)) — クエリ実行時のクエリキャッシュの使用状況。値: ‘Unknown’ = 状態不明、‘None’ = クエリ結果はクエリ結果キャッシュに書き込まれず、クエリ結果キャッシュからも読み出されませんでした、‘Write’ = クエリ結果はクエリ結果キャッシュに書き込まれました、‘Read’ = クエリ結果はクエリ結果キャッシュから読み出されました。
  • asynchronous_read_counters (Map(LowCardinality(String), UInt64)) — 非同期読み込みのメトリクス。
  • is_internal (UInt8) — 内部で実行される補助クエリかどうかを示します。
別名:
  • ProfileEvents.Names — mapKeys(ProfileEvents) の別名です。
  • ProfileEvents.Values — mapValues(ProfileEvents) の別名です。
  • Settings.Names — mapKeys(Settings) の別名です。
  • Settings.Values — mapValues(Settings) の別名です。

例

基本的な例
Cloud の例 ClickHouse Cloud では、system.query_log は各ノードごとにローカルです。すべてのエントリを確認するには、clusterAllReplicas 経由でクエリする必要があります。 たとえば、“default” クラスター内のすべてのレプリカの query_log の行を集約するには、次のように記述できます。

関連項目

  • system.query_thread_log — このテーブルには、各クエリ実行スレッドの情報が含まれています。
  • system.session_query_ids — このテーブルには、現在のセッションで実行されたクエリのクエリ ID が含まれており、ログの中から自分自身のクエリを見つけるのに役立ちます。
最終更新日 2026年9月26日