ClickHouse/docs/ja/sql-reference/statements/misc.md

machine_translated	machine_translated_rev	toc_priority	toc_title
true	d734a8e46d	39	その他

その他のクエリ

ATTACH

このクエリは CREATE、しかし

• 単語の代わりに CREATE それは単語を使用します ATTACH.
• クエリはディスク上にデータを作成しませんが、データがすでに適切な場所にあるとみなし、テーブルに関する情報をサーバーに追加するだけです。 添付クエリを実行すると、サーバーはテーブルの存在を知ることになります。

テーブルが以前に分離されていた場合 (DETACH）、その構造が知られていることを意味し、構造を定義することなく省略形を使用することができます。

ATTACH TABLE [IF NOT EXISTS] [db.]name [ON CLUSTER cluster]

このクエリは、サーバーの起動時に使用されます。 サーバーに店舗のテーブルメタデータとしてファイル ATTACH クエリは、起動時に実行されるだけです（サーバー上に明示的に作成されたシステムテーブルは例外です）。

CHECK TABLE

Trueの場合、ただちにパージを行うデータをテーブルが壊れる可能性があります。

CHECK TABLE [db.]name

その CHECK TABLE queryは、実際のファイルサイズをサーバーに格納されている期待値と比較します。 ファイルサイズが格納された値と一致しない場合は、データが破損していることを意味します。 このが発生する可能性があります、例えば、システムがクラッシュ時のクエリを実行します。

のクエリーの応答を含む result 単一行の列。 行に値がのあります ブール値 タイプ:

• 0-テーブル内のデータが破損しています。
• 1-データは整合性を維持します。

その CHECK TABLE クエリは以下のテーブルエンジン:

• ログ
• TinyLog
• ストリップログ
• マージツリーファミリー

これは、テーブルが別のテーブルエンジンの原因となる例外です。

からのエンジン *Log 家族は失敗の自動データ回復を提供しない。 を使用 CHECK TABLE タイムリーにデータ損失を追跡するためのクエリ。

のために MergeTree 家族のエンジンは、 CHECK TABLE クエリを示すステータス確認のための個人データのテーブルに現地サーバーです。

データが破損している場合

テーブルが破損している場合は、破損していないデータを別のテーブルにコピーできます。 これを行うには:

1. 破損したテーブルと同じ構造の新しいテーブルを作成します。 このためクセスしてください CREATE TABLE <new_table_name> AS <damaged_table_name>.
2. セットを max_threads 単一のスレッドで次のクエリを処理するには、1の値を指定します。 これを行うにはクエリを実行します SET max_threads = 1.
3. クエリの実行 INSERT INTO <new_table_name> SELECT * FROM <damaged_table_name>. この要求にコピーする非破損データからの表-別表に示す。 破損した部分の前のデータのみがコピーされます。
4. 再起動する clickhouse-client リセットするには max_threads 値。

DESCRIBE TABLE

DESC|DESCRIBE TABLE [db.]table [INTO OUTFILE filename] [FORMAT format]

以下を返します String タイプ列:

• name — Column name.
• type— Column type.
• default_type — Clause that is used in 既定の式 (DEFAULT, MATERIALIZED または ALIAS). 既定の式が指定されていない場合、Columnには空の文字列が含まれます。
• default_expression — Value specified in the DEFAULT 句。
• comment_expression — Comment text.

入れ子にされたデータ構造は “expanded” フォーマット。 各列は別々に表示され、名前はドットの後に続きます。

DETACH

に関する情報を削除します。 ‘name’ サーバーからのテーブル。 サーバーはテーブルの存在を知ることをやめます。

DETACH TABLE [IF EXISTS] [db.]name [ON CLUSTER cluster]

テーブルのデータやメタデータは削除されません。 次のサーバーの起動時に、サーバーはメタデータを読み取り、再度テーブルについて調べます。 同様に、 “detached” 表はを使用して再付けることができます ATTACH クエリ(メタデータが格納されていないシステムテーブルを除く)。

ありません DETACH DATABASE クエリ。

DROP

このクエ: DROP DATABASE と DROP TABLE.

DROP DATABASE [IF EXISTS] db [ON CLUSTER cluster]

内部のすべてのテーブルを削除 ‘db’ データベース、その後削除 ‘db’ データベース自体。 もし IF EXISTS データベースが存在しない場合、エラーは返されません。

DROP [TEMPORARY] TABLE [IF EXISTS] [db.]name [ON CLUSTER cluster]

テーブルを削除します。 もし IF EXISTS テーブルが存在しない場合、またはデータベースが存在しない場合は、エラーを返しません。

DROP DICTIONARY [IF EXISTS] [db.]name

辞書をdeletsします。 もし IF EXISTS テーブルが存在しない場合、またはデータベースが存在しない場合は、エラーを返しません。

EXISTS

EXISTS [TEMPORARY] [TABLE|DICTIONARY] [db.]name [INTO OUTFILE filename] [FORMAT format]

シングルを返します UInt8-単一の値を含むタイプの列 0 テーブルまたはデータベースが存在しない場合、または 1 指定されたデータベースにテーブルが存在する場合。

KILL QUERY

KILL QUERY [ON CLUSTER cluster]
  WHERE <where expression to SELECT FROM system.processes query>
  [SYNC|ASYNC|TEST]
  [FORMAT format]

現在実行中のクエリを強制的に終了しようとします。 終了するクエリは、システムから選択されます。プロセステーブルで定義された基準を使用して、 WHERE の句 KILL クエリ。

例:

-- Forcibly terminates all queries with the specified query_id:
KILL QUERY WHERE query_id='2-857d-4a57-9ee0-327da5d60a90'

-- Synchronously terminates all queries run by 'username':
KILL QUERY WHERE user='username' SYNC

読み取り専用ユーザーは、自分のクエリのみを停止できます。

既定では、非同期バージョンのクエリが使用されます (ASYNC）、クエリが停止したことの確認を待つことはありません。

同期バージョン (SYNC)待機のためのすべての問い合わせに対応停止に関する情報を表示し各工程で停止します。 応答には、 kill_status 次の値を取ることができる列:

1. ‘finished’ – The query was terminated successfully.
2. ‘waiting’ – Waiting for the query to end after sending it a signal to terminate.
3. The other values ​​explain why the query can’t be stopped.

テストクエリ (TEST）ユーザーの権限のみをチェックし、停止するクエリのリストを表示します。

KILL MUTATION

KILL MUTATION [ON CLUSTER cluster]
  WHERE <where expression to SELECT FROM system.mutations query>
  [TEST]
  [FORMAT format]

キャンセルと削除を試みます 突然変異 これは現在実行中です。 取り消すべき突然変異はから選ばれます system.mutations テーブルのフィルタで指定された WHERE の句 KILL クエリ。

テストクエリ (TEST）ユーザーの権限のみをチェックし、停止するクエリのリストを表示します。

例:

-- Cancel and remove all mutations of the single table:
KILL MUTATION WHERE database = 'default' AND table = 'table'

-- Cancel the specific mutation:
KILL MUTATION WHERE database = 'default' AND table = 'table' AND mutation_id = 'mutation_3.txt'

The query is useful when a mutation is stuck and cannot finish (e.g. if some function in the mutation query throws an exception when applied to the data contained in the table).

突然変異によって既に行われた変更はロールバックされません。

OPTIMIZE

OPTIMIZE TABLE [db.]name [ON CLUSTER cluster] [PARTITION partition | PARTITION ID 'partition_id'] [FINAL] [DEDUPLICATE]

このクエリを初期化予定外の統合データのパーツを使ったテーブルのテーブルエンジンからの MergeTree 家族

その OPTMIZE クエリもサポートされています MaterializedView そして バッファ エンジン その他のテーブルエンジンなサポート。

とき OPTIMIZE とともに使用されます レプリケートされたmergetree テーブルエンジンのファミリ、ClickHouseはマージのためのタスクを作成し、すべてのノードでの実行を待ちます。 replication_alter_partitions_sync 設定が有効になっています)。

• もし OPTIMIZE 何らかの理由でマージを実行せず、クライアントに通知しません。 通知を有効にするには、以下を使用します optimize_throw_if_noop 設定。
• を指定した場合 PARTITION 指定したパーティションのみが最適化されます。 パーティション式の設定方法.
• 指定した場合 FINAL、最適化は、すべてのデータがすでに一つの部分にある場合でも行われる。
• 指定した場合 DEDUPLICATE、その後、完全に同一の行が重複排除されます（すべての列が比較されます）、それだけでMergeTreeエンジンのために理にかなっています。

!!! warning "警告" OPTIMIZE 修正できません “Too many parts” エラー。

RENAME

テーブルの名前を変更します。

RENAME TABLE [db11.]name11 TO [db12.]name12, [db21.]name21 TO [db22.]name22, ... [ON CLUSTER cluster]

すべてのテーブル名変更"グローバルチェンジにおけるロックしなければなりません。 テーブルの名前を変更するのは簡単な操作です。 場合は正しく表示す他のデータベースのテーブルに表示されるようになります。本データベースです。 しかし、そのディレクトリのデータベースに格納してある必要がある同一ファイルシステム(それ以外の場合、エラーを返す。

SET

SET param = value

割り当て value に param 設定 現在のセッションの場合。 変更はできません サーバー設定 こっちだ

また、指定した設定プロファイルのすべての値を単一のクエリで設定することもできます。

SET profile = 'profile-name-from-the-settings-file'

詳細については、 設定.

TRUNCATE

TRUNCATE TABLE [IF EXISTS] [db.]name [ON CLUSTER cluster]

表からすべてのデータを削除します。 ときに句 IF EXISTS テーブルが存在しない場合、クエリはエラーを返します。

その TRUNCATE queryはサポートされていません ビュー, ファイル, URL と ヌル テーブルエンジン。

USE

USE db

セッションの現在のデータベースを設定できます。 現在のデータベース検索用テーブルの場合はデータベースが明示的に定義されたクエリードの前にテーブルの名前です。 このクエリできません利用の場合は、httpプロトコルが存在しない概念です。

元の記事