重要

現在表示されているページは、TiDBのアーカイブされたドキュメント (非更新) です。TiDBをご利用の場合、最新のLTS (Long Term Support) バージョンの使用を推奨します。

重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

SQL に関するよくある質問

このドキュメントは、TiDB での SQL 操作に関する FAQ をまとめたものです。

TiDB はセカンダリキーをサポートしていますか?

はい。一意の副次索引を持つ非主キー列にNOT NULL制約を持つことができます。この場合、列は 2 次キーとして機能します。

大きなテーブルで DDL 操作を実行するとき、TiDB はどのように動作しますか?

通常、大きなテーブルに対する TiDB の DDL 操作は問題になりません。 TiDB はオンライン DDL 操作をサポートしており、これらの DDL 操作は DML 操作をブロックしません。

列の追加、列の削除、インデックスの削除などの一部の DDL 操作では、TiDB はこれらの操作をすばやく実行できます。

インデックスの追加などの重い DDL 操作の場合、TiDB はデータをバックフィルする必要があります。これには (テーブルのサイズによっては) 時間がかかり、追加のリソースが消費されます。オンライントラフィックへの影響は調整可能です。 TiDB は複数のスレッドでバックフィルを実行でき、消費されるリソースは次のシステム変数で設定できます。

適切なクエリプランを選択する方法ヒントを使用する必要がありますか?または、ヒントを使用できますか？

TiDB には、コストベースのオプティマイザが含まれています。ほとんどの場合、オプティマイザーが最適なクエリプランを選択します。オプティマイザがうまく機能しない場合でも、オプティマイザーのヒントを使用してオプティマイザに介入できます。

さらに、 SQL バインディングを使用して、特定の SQL ステートメントのクエリプランを修正することもできます。

特定の SQL ステートメントの実行を防ぐ方法は?

MAX_EXECUTION_TIMEヒントを使用してSQL バインディングを作成し、特定のステートメントの実行時間を小さな値 (1 ミリ秒など) に制限できます。このように、ステートメントはしきい値によって自動的に終了します。

たとえば、 SELECT * FROM t1, t2 WHERE t1.id = t2.idの実行を防ぐには、次の SQL バインディングを使用してステートメントの実行時間を 1 ミリ秒に制限します。

CREATE GLOBAL BINDING for
    SELECT * FROM t1, t2 WHERE t1.id = t2.id
USING
    SELECT /*+ MAX_EXECUTION_TIME(1) */ * FROM t1, t2 WHERE t1.id = t2.id;

ノート：
MAX_EXECUTION_TIMEの精度は約 100 ミリ秒です。 TiDB が SQL ステートメントを終了する前に、TiKV のタスクが開始される場合があります。このような場合に TiKV リソースの消費を抑えるには、 tidb_enable_paging ～ ONを設定することをお勧めします。

この SQL バインドを削除すると、制限が削除されます。

DROP GLOBAL BINDING for
    SELECT * FROM t1, t2 WHERE t1.id = t2.id;

TiDB と互換性のある MySQL 変数は何ですか?

システム変数を参照してください。

`ORDER BY`を省略した場合、結果の順序が MySQL とは異なります

これはバグではありません。レコードのデフォルトの順序は、さまざまな状況に依存し、一貫性は保証されません。

クエリは単一のスレッドで実行されるため、MySQL での結果の順序は安定しているように見える場合があります。ただし、新しいバージョンにアップグレードすると、クエリプランが変更されることがよくあります。結果の順序が必要な場合は常にORDER BYを使用することをお勧めします。

参考文献はISO/IEC 9075:1992、データベース言語 SQL - 1992 年 7 月 30 日にあり、次のように述べられています。

<order by clause>が指定されていない場合、 <cursor specification>で指定されたテーブルは T であり、T 内の行の順序は実装に依存します。

次の 2 つのクエリでは、両方の結果が有効であると見なされます。

> select * from t;
+------+------+
| a    | b    |
+------+------+
|    1 |    1 |
|    2 |    2 |
+------+------+
2 rows in set (0.00 sec)

> select * from t; -- the order of results is not guaranteed
+------+------+
| a    | b    |
+------+------+
|    2 |    2 |
|    1 |    1 |
+------+------+
2 rows in set (0.00 sec)

ORDER BYで使用される列のリストが一意でない場合、ステートメントも非決定論的と見なされます。次の例では、列aに重複した値があります。したがって、 ORDER BY a, bだけが決定論的に保証されます。

> select * from t order by a;
+------+------+
| a    | b    |
+------+------+
|    1 |    1 |
|    2 |    1 |
|    2 |    2 |
+------+------+
3 rows in set (0.00 sec)

次のステートメントでは、列aの順序は保証されますが、列bの順序は保証されません。

> select * from t order by a;
+------+------+
| a    | b    |
+------+------+
|    1 |    1 |
|    2 |    2 |
|    2 |    1 |
+------+------+
3 rows in set (0.00 sec)

TiDB は`SELECT FOR UPDATE`をサポートしていますか?

はい。悲観的ロック (TiDB v3.0 以降のデフォルト) を使用する場合、 SELECT FOR UPDATEの実行は MySQL と同様に動作します。

楽観的ロックを使用する場合、 SELECT FOR UPDATEはトランザクションの開始時にデータをロックしませんが、トランザクションのコミット時に競合をチェックします。チェックで競合が明らかになった場合、コミットしているトランザクションはロールバックします。

詳細については、 SELECT構文要素の説明を参照してください。

TiDB のコーデックは、UTF-8 文字列が memcomparable であることを保証できますか?キーが UTF-8 をサポートする必要がある場合、コーディングに関する提案はありますか?

TiDB はデフォルトで UTF-8 文字セットを使用し、現在は UTF-8 のみをサポートしています。 TiDB の文字列は memcomparable 形式を使用します。

トランザクション内のステートメントの最大数はいくつですか?

トランザクション内のステートメントの最大数は、デフォルトで 5000 です。

オプティミスティックトランザクションモードでは、トランザクションの再試行が有効になっている場合、デフォルトの上限は 5000 ですstmt-count-limitパラメータを使用して制限を調整できます。

後で挿入されたデータの自動インクリメント ID が、以前に TiDB に挿入されたデータよりも小さいのはなぜですか?

TiDB の自動インクリメント ID 機能は、自動的にインクリメンタルで一意であることのみが保証されていますが、順次割り当てられることは保証されていません。現在、TiDB は ID をバッチで割り当てています。データが複数の TiDB サーバーに同時に挿入される場合、割り当てられる ID は連続しません。複数のスレッドが同時に複数のtidb-serverインスタンスにデータを挿入すると、後で挿入されるデータの自動インクリメント ID が小さくなることがあります。 TiDB では、整数フィールドにAUTO_INCREMENTを指定できますが、1 つのテーブルにAUTO_INCREMENTフィールドを 1 つだけ指定できます。詳細については、自動インクリメント IDおよびAUTO_INCREMENT 属性を参照してください。

`sql_mode`で sql_mode を変更するにはどうすればよいですか?

TiDB は、SESSION または GLOBAL ベースでのsql_modeシステム変数の変更をサポートしています。

GLOBALのスコープ変数への変更は、クラスターの残りのサーバーに伝達され、再起動後も保持されます。これは、各 TiDBサーバーでsql_modeの値を変更する必要がないことを意味します。
SESSIONのスコープ変数への変更は、現在のクライアントセッションにのみ影響します。サーバーを再起動すると、変更が失われます。

エラー: `java.sql.BatchUpdateExecption:statement count 5001 exceeds the transaction limitation`ます

Sqoop では、 --batchは各バッチで 100 個のステートメントをコミットすることを意味しますが、デフォルトでは各ステートメントには 100 個の SQL ステートメントが含まれます。したがって、100 * 100 = 10000 SQL ステートメントとなり、1 つの TiDB トランザクションで許可されるステートメントの最大数である 5000 を超えます。

2 つのソリューション:

次のように-Dsqoop.export.records.per.statement=10オプションを追加します。

sqoop export \
    -Dsqoop.export.records.per.statement=10 \
    --connect jdbc:mysql://mysql.example.com/sqoop \
    --username sqoop ${user} \
    --password ${passwd} \
    --table ${tab_name} \
    --export-dir ${dir} \
    --batch

1 つの TiDB トランザクション内のステートメントの制限数を増やすこともできますが、これはより多くのメモリを消費します。詳細については、 SQL ステートメントの制限を参照してください。

TiDB には Oracle の Flashback Query のような機能がありますか? DDLをサポートしていますか?

はい、そうです。また、DDLもサポートしています。詳細については、 AS OF TIMESTAMP句を使用した履歴データの読み取りを参照してください。

TiDB はデータを削除した直後にスペースを解放しますか?

DELETE 、 TRUNCATE 、およびDROPの操作のいずれも、データをすぐに解放しません。 TRUNCATEとDROPの操作では、TiDB GC (ガベージコレクション) 時間 (既定では 10 分) の後、データが削除され、スペースが解放されます。 DELETE回の操作では、データは削除されますが、圧縮が実行されるまでスペースはすぐには解放されません。

データが削除された後、クエリの速度が遅くなるのはなぜですか?

大量のデータを削除すると、多くの不要なキーが残り、クエリの効率に影響します。この問題を解決するには、リージョンマージの機能を使用できます。詳細はTiDB ベストプラクティスのデータセクションの削除を参照してください。

データを削除した後、ストレージスペースを再利用するのが遅い場合はどうすればよいですか?

TiDB はマルチバージョン同時実行制御 (MVCC) を使用するため、古いデータが新しいデータで上書きされる場合、古いデータは置き換えられず、新しいデータと共に保持されます。タイムスタンプは、データのバージョンを識別するために使用されます。データを削除しても、すぐにスペースが再利用されるわけではありません。同時トランザクションが以前のバージョンの行を参照できるように、ガベージコレクションが遅延されます。これはtidb_gc_life_time (デフォルト: 10m0s ) システム変数で設定できます。

`SHOW PROCESSLIST`はシステムプロセス ID を表示しますか?

TiDB SHOW PROCESSLISTの表示内容は MySQL SHOW PROCESSLISTとほぼ同じです。 TiDB SHOW PROCESSLISTはシステムプロセス ID を表示しません。表示される ID は、現在のセッション ID です。 TiDB SHOW PROCESSLISTと MySQL SHOW PROCESSLISTの違いは次のとおりです。

TiDB は分散データベースであるため、 tidb-serverつのインスタンスは SQL ステートメントを解析および実行するためのステートレスエンジンです (詳細については、 TiDBアーキテクチャを参照してください)。 SHOW PROCESSLISTは、クラスターで実行されているすべてのセッションのリストではなく、ユーザーが MySQL クライアントからログインするtidb-serverインスタンスで実行されたセッションのリストを表示します。しかし、MySQL はスタンドアロンデータベースであり、そのSHOW PROCESSLISTには MySQL で実行されたすべての SQL ステートメントが表示されます。
TiDB のState列は、クエリの実行中に継続的に更新されるわけではありません。 TiDB は並列クエリをサポートしているため、各ステートメントは一度に複数の状態になる可能性があるため、単一の値に単純化することは困難です。

SQLコミットの実行優先度を制御または変更する方法は?

グローバルセッションごとまたは個々のステートメント単位での優先度の変更をサポートしています。プライオリティには次の意味があります。

HIGH_PRIORITY : このステートメントの優先度が高い。つまり、TiDB はこのステートメントに優先順位を与え、最初に実行します。
LOW_PRIORITY : このステートメントの優先度は低いです。つまり、実行期間中、TiDB はこのステートメントの優先度を下げます。

上記の 2 つのパラメーターを TiDB の DML と組み合わせて使用できます。例えば：

データベースに SQL ステートメントを記述して、優先順位を調整します。

select HIGH_PRIORITY | LOW_PRIORITY count(*) from table_name;
insert HIGH_PRIORITY | LOW_PRIORITY into table_name insert_values;
delete HIGH_PRIORITY | LOW_PRIORITY from table_name;
update HIGH_PRIORITY | LOW_PRIORITY table_reference set assignment_list where where_condition;
replace HIGH_PRIORITY | LOW_PRIORITY into table_name;

フルテーブルスキャンステートメントは、自動的に低い優先度に調整されます。デフォルトでは、 analyzeの優先度は低くなります。

TiDB での`auto analyze`のトリガー戦略は何ですか?

トリガー戦略: auto analyzeは、新しいテーブルの行数が 1000 に達し、このテーブルに 1 分間書き込み操作がない場合に自動的にトリガーされます。

比率 (変更された行数 / 現在の合計行数) がtidb_auto_analyze_ratioより大きい場合、 analyzeステートメントが自動的にトリガーされます。デフォルト値のtidb_auto_analyze_ratioは 0.5 で、この機能がデフォルトで有効になっていることを示します。安全性を確保するために、この機能が有効になっているときの最小値は 0.3 であり、デフォルト値が 0.8 であるpseudo-estimate-ratioよりも小さくする必要があります。そうしないと、一定期間疑似統計が使用されます。 tidb_auto_analyze_ratio ～ 0.5 に設定することをお勧めします。

auto analyzeを無効にするには、システム変数tidb_enable_auto_analyzeを使用します。

オプティマイザーのヒントを使用してオプティマイザーの動作をオーバーライドできますか?

TiDB は、ヒントやSQL計画管理など、デフォルトのクエリオプティマイザーの動作をオーバーライドする複数の方法をサポートしています。基本的な使用法は MySQL に似ていますが、TiDB 固有の拡張機能がいくつかあります。

SELECT column_name FROM table_name USE INDEX（index_name）WHERE where_condition;

`Information schema is changed`エラーが報告されるのはなぜですか?

TiDB は、時間のschemaを使用して SQL ステートメントを処理し、オンラインの非同期 DDL 変更をサポートします。 DML ステートメントと DDL ステートメントは同時に実行される可能性があり、各ステートメントが同じschemaを使用して実行されるようにする必要があります。したがって、DML 操作が進行中の DDL 操作と一致すると、 Information schema is changedエラーが報告されることがあります。 DML 操作中のエラー報告が多すぎるのを防ぐために、いくつかの改善が行われました。

現在、このエラー報告にはまだいくつかの原因があります。

原因 1: DML 操作に含まれるいくつかのテーブルは、進行中の DDL 操作に含まれるテーブルと同じです。進行中の DDL 操作を確認するには、 ADMIN SHOW DDLステートメントを使用します。
原因 2: DML 操作が長時間続いています。この期間中、多くの DDL ステートメントが実行され、1024 を超えるバージョン変更が発生しschemaた。このデフォルト値は、変数tidb_max_delta_schema_countを変更することで変更できます。
原因 3: DML 要求を受け入れる TiDBサーバーが長時間schema informationをロードできません (TiDB と PD または TiKV の間の接続障害が原因である可能性があります)。この期間中、多くのschemaステートメントが実行され、100 以上のバージョン変更が発生しました。
原因 4: TiDB の再起動後、最初の DDL 操作が実行される前に、DML 操作が実行され、最初の DDL 操作が発生します (つまり、最初の DDL 操作が実行される前に、DML に対応するトランザクションが開始されます。 DDL の最初のschemaのバージョンが変更され、DML に対応するトランザクションがコミットされます)、この DML 操作はこのエラーを報告します。

上記の原因のうち、原因 1 のみがテーブルに関連しています。関連する DML 操作は失敗後に再試行されるため、原因 1 と原因 2 はアプリケーションに影響しません。原因 3 については、TiDB と TiKV/PD 間のネットワークを確認する必要があります。

ノート：
現在、TiDB はschemaのバージョン変更をすべてキャッシュするわけではありません。
DDL 操作ごとに、 schemaのバージョン変更の数は、対応するschema stateのバージョン変更の数と同じです。
DDL 操作が異なれば、 schemaのバージョン変更の数も異なります。たとえば、 CREATE TABLEステートメントではschemaのバージョン変更が 1 回行われますが、 ADD COLUMNステートメントでは 4 回のバージョン変更が行われます。

「情報スキーマが古くなっています」エラーの原因は何ですか?

DML ステートメントの実行時に、TiDB が DDL リース (デフォルトでは 45 秒) 内で最新のスキーマをロードできなかった場合、 Information schema is out of dateエラーが発生する可能性があります。考えられる原因は次のとおりです。

この DML を実行した TiDB インスタンスが強制終了され、この DML ステートメントに対応するトランザクションの実行に DDL リースよりも時間がかかりました。トランザクションがコミットされたときに、エラーが発生しました。
TiDB は、この DML ステートメントの実行中に PD または TiKV に接続できませんでした。その結果、キープアライブ設定が原因で、TiDB が DDL リース内のスキーマのロードに失敗したか、PD から切断されました。

高い同時実行性の下で DDL ステートメントを実行するとエラーが報告されますか?

高い並行性で DDL ステートメント (バッチでのテーブルの作成など) を実行すると、同時実行中のキーの競合が原因で、これらのステートメントのごく一部が失敗する可能性があります。

同時 DDL ステートメントの数を 20 未満に保つことをお勧めします。それ以外の場合は、失敗したステートメントをクライアントから再試行する必要があります。

SQL 最適化

TiDB 実行計画の説明

クエリ実行計画を理解するを参照してください。

統計収集

統計入門を参照してください。

`select count(1)`を最適化する方法は?

count(1)ステートメントは、テーブル内の行の総数をカウントします。並行性の程度を向上させると、速度が大幅に向上する可能性があります。同時実行数を変更するには、 tidb_distsql_scan_concurrencyドキュメントを参照してください。ただし、CPU および I/O リソースにも依存します。 TiDB はすべてのクエリで TiKV にアクセスします。データ量が少ない場合、MySQL はすべてメモリ内にあり、TiDB はネットワークアクセスを行う必要があります。

推奨事項:

ハードウェア構成を改善します。ソフトウェアとハードウェアの要件を参照してください。
同時性を改善します。デフォルト値は 10 です。50 に改善して試してみることができます。ただし、通常、改善はデフォルト値の 2 ～ 4 倍です。
大量のデータの場合はcountをテストします。
TiKV 構成を最適化します。 TiKV スレッドのパフォーマンスを調整するとTiKV メモリパフォーマンスの調整を参照してください。
コプロセッサキャッシュを有効にします。

現在の DDL ジョブの進行状況を表示する方法は?

ADMIN SHOW DDLを使用して、現在の DDL ジョブの進行状況を表示できます。操作は次のとおりです。

ADMIN SHOW DDL;

*************************** 1. row ***************************
  SCHEMA_VER: 140
       OWNER: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc
RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganization, SchemaID:1, TableID:118, RowCount:77312, ArgLen:0, start time: 2018-12-05 16:26:10.652 +0800 CST, Err:<nil>, ErrCount:0, SnapshotVersion:404749908941733890
     SELF_ID: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc

上記の結果から、 ADD INDEXの操作が現在処理中であることがわかります。 RUNNING_JOBS列のRowCountフィールドから、 ADD INDEX操作で 77312 行のインデックスが追加されたことを取得することもできます。

DDL ジョブを表示する方法

ADMIN SHOW DDL : 実行中の DDL ジョブを表示する
ADMIN SHOW DDL JOBS : 現在の DDL ジョブキュー内のすべての結果 (実行中および実行待ちのタスクを含む) と、完了した DDL ジョブキュー内の最後の 10 個の結果を表示します。
ADMIN SHOW DDL JOBS QUERIES 'job_id' [, 'job_id'] ... : job_idに対応する DDL タスクの元の SQL ステートメントを表示します。 job_idは実行中の DDL ジョブのみを検索し、最後の 10 個の結果は DDL 履歴ジョブキューに格納されます。

TiDB は CBO (Cost-Based Optimization) をサポートしていますか?はいの場合、どの程度ですか？

はい。 TiDB はコストベースのオプティマイザーを使用します。コストモデルと統計は常に最適化されています。 TiDB は、ハッシュ結合やソートマージ結合などの結合アルゴリズムもサポートしています。

テーブルで`analyze`を実行する必要があるかどうかを判断するにはどうすればよいですか?

SHOW STATS_HEALTHYを使用してHealthyフィールドをビューし、通常、フィールド値が 60 より小さい場合、テーブルでANALYZEを実行する必要があります。

クエリプランをツリーとして表示する場合の ID ルールは何ですか?このツリーの実行順序は?

これらの ID にルールはありませんが、ID は一意です。 ID が生成されるとカウンターが機能し、1 つのプランが生成されると 1 つ追加されます。実行順序は ID とは関係ありません。クエリプラン全体がツリーであり、実行プロセスはルートノードから開始され、データは継続的に上位レベルに返されます。クエリプランの詳細については、 TiDB クエリ実行プランを理解するを参照してください。

TiDB クエリプランでは、 `cop`タスクは同じルートにあります。それらは同時に実行されますか？

現在、TiDB のコンピューティングタスクは、 cop taskとroot taskの 2 つの異なるタイプのタスクに属しています。

cop taskは、分散実行のために KV エンドにプッシュされるコンピューティングタスクです。 root taskは、TiDB 側でのシングルポイント実行のコンピューティングタスクです。

通常、 root taskの入力データはcop taskから取得されます。 root task台がデータを処理すると、TiKVのcop task台が同時にデータを処理でき、TiDBのroot task台のプルを待ちます。したがって、 copのタスクはroot taskと同時に実行されると見なすことができます。しかし、彼らのデータには上流と下流の関係があります。実行プロセス中、それらはしばらくの間同時に実行されます。たとえば、最初のcop taskは [100, 200] のデータを処理し、2 番目のcop taskは [1, 100] のデータを処理しています。詳しくはTiDB クエリプランを理解するをご覧ください。

データベースの最適化

TiDB オプションの編集

TiDB コマンドオプションを参照してください。

ホットスポットの問題を回避し、負荷分散を実現する方法は?ホットパーティションまたは範囲は TiDB の問題ですか?

ホットスポットの原因となるシナリオについては、一般的な鍋を参照してください。次の TiDB 機能は、ホットスポットの問題を解決するのに役立つように設計されています。

SHARD_ROW_ID_BITS属性。この属性を設定すると、行 ID が分散されて複数のリージョンに書き込まれるため、書き込みホットスポットの問題を軽減できます。
自動インクリメント主キーによってもたらされるホットスポットを解決するのに役立つAUTO_RANDOM属性。
コプロセッサキャッシュ、小さなテーブルの読み取りホットスポット用。
ロードベーススプリット、小さなテーブルのフルテーブルスキャンなど、リージョン間の不均衡なアクセスによって発生するホットスポットの場合。

ホットスポットが原因でパフォーマンスの問題が発生した場合は、ホットスポットの問題のトラブルシューティングを参照して解決してください。

ホットスポットを分散させる方法は?

TiDB では、データをリージョンに分割して管理します。一般に、TiDB ホットスポットはリージョン内の読み取り/書き込みホットスポットを意味します。 TiDB では、主キー (PK) が整数ではない、または PK を持たないテーブルの場合、 SHARD_ROW_ID_BITSを構成してリージョンのホットスポットを分散させることで、リージョンを適切に分割できます。詳しくはSHARD_ROW_ID_BITS in SHARD_ROW_ID_BITSの紹介をご覧ください。

TiKV のパフォーマンスを調整する

TiKV スレッドのパフォーマンスを調整するとTiKV メモリパフォーマンスの調整を参照してください。