重要

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

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 では、システム変数tidb_enable_ordered_result_modeを使用して、最終出力結果を自動的にソートすることもできます。

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

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

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

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

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

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

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

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

楽観的トランザクションモードでは、トランザクションの再試行が有効にstmt-count-limitている場合、デフォルトの上限は 5000 です。1 パラメータを使用して制限を調整できます。

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

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

TiDB で`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 ベストプラクティスのデータセクションの削除を参照してください。

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

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コミットの実行優先度を制御または変更する方法は?

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

HIGH_PRIORITY : このステートメントの優先度が高い。つまり、TiDB はこのステートメントに優先順位を与え、最初に実行します。
LOW_PRIORITY : このステートメントの優先度は低いです。つまり、実行期間中、TiDB はこのステートメントの優先度を下げます。
DELAYED : このステートメントは通常の優先度を持ち、 tidb_force_priorityに対するNO_PRIORITY設定と同じです。

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

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

SELECT HIGH_PRIORITY | LOW_PRIORITY | DELAYED COUNT(*) FROM table_name;
INSERT HIGH_PRIORITY | LOW_PRIORITY | DELAYED INTO table_name insert_values;
DELETE HIGH_PRIORITY | LOW_PRIORITY | DELAYED FROM table_name;
UPDATE HIGH_PRIORITY | LOW_PRIORITY | DELAYED table_reference SET assignment_list WHERE where_condition;
REPLACE HIGH_PRIORITY | LOW_PRIORITY | DELAYED 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;

DDL の実行

このセクションでは、DDL ステートメントの実行に関連する問題をリストします。 DDL 実行の原則に関する詳細な説明については、 DDL ステートメントの実行原則とベストプラクティスを参照してください。

さまざまな DDL 操作を実行するのにどのくらいの時間がかかりますか?

DDL 操作がブロックされておらず、各 TiDBサーバーがスキーマバージョンを正常に更新でき、DDL 所有者ノードが正常に動作しているとします。この場合、さまざまな DDL 操作の推定時間は次のようになります。

DDL操作タイプ	予定時刻
`ADD INDEX` 、 `MODIFY COLUMN`などの再編成 DDL (再編成タイプのデータ変更)	データ量、システム負荷、DDL パラメータの設定によって異なります。
`CREATE DATABASE` 、 `CREATE TABLE` 、 `DROP DATABASE` 、 `DROP TABLE` 、 `TRUNCATE TABLE` 、 `ALTER TABLE ADD` 、 `ALTER TABLE DROP` 、 `MODIFY COLUMN` (メタデータの変更のみ)、 `DROP INDEX`などの一般的な DDL (Reorg 以外の DDL タイプ)	約1秒

ノート：
上記は施術時間の目安です。実際の時間は異なる場合があります。

DDL の実行が遅い考えられる理由

ユーザーセッションで、DDL ステートメントの前に非自動コミット DML ステートメントがあり、非自動コミット DML ステートメントのコミット操作が遅いと、DDL ステートメントの実行が遅くなります。つまり、TiDB は DDL ステートメントを実行する前に、コミットされていない DML ステートメントをコミットします。
複数の DDL ステートメントが一緒に実行されると、後の DDL ステートメントの実行は、キューで待機する必要がある可能性があるため、遅くなる可能性があります。キューイングのシナリオは次のとおりです。
- 同じタイプの DDL ステートメントをキューに入れる必要があります。たとえば、 CREATE TABLEとCREATE DATABASEはどちらも一般的な DDL ステートメントであるため、両方の操作を同時に実行する場合は、キューに入れる必要があります。 TiDB v6.2.0 以降では、並列 DDL ステートメントがサポートされていますが、あまりにも多くの TiDB コンピューティングリソースを使用して DDL を実行することを避けるために、同時実行制限もあります。 DDL が同時実行制限を超えると、キューイングが発生します。
- 同じテーブルに対して実行される DDL 操作には、それらの間に依存関係があります。後の DDL ステートメントは、前の DDL 操作が完了するまで待機する必要があります。
クラスターが正常に開始された後、DDL モジュールが DDL 所有者を選択しているため、最初の DDL 操作の実行時間が比較的長くなる場合があります。
TiDB が終了し、TiDB が PD と正常に通信できなくなります (電源オフ状態を含む)。または、TiDB はkill -9コマンドによって終了されます。これにより、TiDB は PD から登録データをタイムリーにクリアしません。
クラスタ内の特定の TiDB ノードと PD または TiKV との間で通信障害が発生し、TiDB が最新のバージョン情報を取得できなくなります。

何が`Information schema is changed`エラーを引き起こしますか?

SQL ステートメントを実行すると、TiDB は分離レベルに基づいてオブジェクトのスキーマバージョンを判断し、それに応じて SQL ステートメントを処理します。 TiDB は、オンラインの非同期 DDL 変更もサポートしています。 DML ステートメントを実行すると、同時に実行される DDL ステートメントが存在する可能性があり、各 SQL ステートメントが同じスキーマで実行されるようにする必要があります。したがって、DML の実行時に DDL 操作が進行中の場合、TiDB はInformation schema is changedエラーを報告することがあります。

v6.4.0 から、TiDB はメタデータロックメカニズムを実装しました。これにより、DML ステートメントと DDL スキーマ変更の調整された実行が可能になり、ほとんどのInformation schema is changedエラーが回避されます。

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

原因 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 の間の接続障害が原因である可能性があります)。この期間中、多くの DDL ステートメントが実行され、 schema以上のバージョン変更が発生しました。
原因 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 回のバージョン変更が行われます。

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

TiDB v6.5.0 より前では、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 未満に保つことをお勧めします。それ以外の場合は、失敗したステートメントをクライアントから再試行する必要があります。

DDL の実行がブロックされるのはなぜですか?

TiDB v6.2.0 より前では、TiDB は、DDL ステートメントのタイプに基づいて、DDL ステートメントを 2 つの先入れ先出しキューに割り当てます。具体的には、Reorg DDL は Reorg キューに移動し、General DDL は一般キューに移動します。先入れ先出しの制限と、同じテーブルで DDL ステートメントを順次実行する必要があるため、実行中に複数の DDL ステートメントがブロックされる場合があります。

たとえば、次の DDL ステートメントについて考えてみます。

DDL 1: CREATE INDEX idx on t(a int);
DDL2: ALTER TABLE t ADD COLUMN b int;
DDL3: CREATE TABLE t1(a int);

先入れ先出しキューの制限により、DDL 3 は DDL 2 の実行を待機する必要があります。また、同じテーブルの DDL ステートメントはシリアルで実行する必要があるため、DDL 2 は DDL 1 が実行されるまで待機する必要があります。したがって、DDL 3 は、異なるテーブルで動作する場合でも、DDL 1 が最初に実行されるまで待機する必要があります。

TiDB v6.2.0 以降、TiDB DDL モジュールは並行フレームワークを使用します。並行フレームワークでは、先入れ先出しキューの制限がなくなりました。代わりに、TiDB はすべての DDL タスクから実行可能な DDL タスクを取得します。さらに、Reorg ワーカーの数が拡張され、ノードあたり約CPU/4になりました。これにより、TiDB は並行フレームワークで同時に複数のテーブルのインデックスを構築できます。

クラスターが新しいクラスターであるか、以前のバージョンからアップグレードされたクラスターであるかに関係なく、TiDB は TiDB v6.2 以降のバージョンで並行フレームワークを自動的に使用します。手動で調整する必要はありません。

スタックした DDL 実行の原因を特定する

DDL ステートメントの実行を遅くするその他の理由を排除します。
次のいずれかの方法を使用して、DDL 所有者ノードを識別します。
- curl http://{TiDBIP}:10080/info/allを使用して、現在のクラスターの所有者を取得します。
- 監視ダッシュボードDDL > DDL META OPMから特定の期間の所有者をビュー。

所有者が存在しない場合は、 curl -X POST http://{TiDBIP}:10080/ddl/owner/resignを使用して手動で所有者の選択をトリガーしてみてください。
所有者が存在する場合は、Goroutine スタックをエクスポートし、スタックしている可能性のある場所を確認します。

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属性。
コプロセッサーキャッシュ、小さなテーブルの読み取りホットスポット用。
ロードベーススプリット、小さなテーブルのフルテーブルスキャンなど、リージョン間の不均衡なアクセスによって発生するホットスポットの場合。
キャッシュされたテーブル、頻繁にアクセスされるがほとんど更新されない小さなホットスポットテーブル用。

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

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

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