重要

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

SQL FAQ

このドキュメントには、TiDB での SQL 操作に関連する FAQ がまとめられています。

TiDB は二次キーをサポートしていますか?

はい。一意のセカンダリインデックスを持つ非主キー列にNOT NULL制約設定できます。この場合、列は 2 次キーとして機能します。

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

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

列の追加、列の削除、インデックスの削除などの一部の DDL 操作については、TiDB はこれらの操作を迅速に実行できます。

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

適切なクエリプランを選択するにはどうすればよいですか?ヒントを使用する必要がありますか?それともヒントを使えばいいのでしょうか？

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

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

特定の SQL ステートメントの実行を防ぐにはどうすればよいですか?

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

たとえば、 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の精度は約 100ms です。 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 です。

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

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

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

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

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

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

エラー: Sqoop を使用して TiDB にデータをバッチで書き込むときに、 `java.sql.BatchUpdateExecption:statement count 5001 exceeds the transaction limitation`

Sqoop では、 --batch各バッチで 100 個のステートメントをコミットすることを意味しますが、デフォルトでは各ステートメントに 100 個の SQL ステートメントが含まれます。したがって、SQL ステートメントは 100 * 100 = 10000 となり、単一の 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

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

TiDBにはOracleのフラッシュバッククエリのような機能はありますか？ 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 はスタンドアロンデータベースであり、MySQL で実行されたSHOW PROCESSLISTの 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 操作の種類	予定時刻
Reorg DDL ( `ADD INDEX` 、 `MODIFY COLUMN`など) (Reorg タイプのデータ変更)	データ量、システム負荷、DDL パラメータ設定によって異なります。
一般的な DDL (Reorg 以外の DDL タイプ)、 `CREATE DATABASE` 、 `CREATE TABLE` 、 `DROP DATABASE` 、 `DROP TABLE` 、 `TRUNCATE TABLE` 、 `ALTER TABLE ADD` 、 `ALTER TABLE DROP` 、 `MODIFY COLUMN` (メタデータのみ変更)、 `DROP INDEX`	約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 ステートメントが実行され、100 を超える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 リースよりも時間がかかりました。トランザクションがコミットされたときにエラーが発生しました。
この DML ステートメントの実行中に、TiDB は 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);
DDL 2: ALTER TABLE t ADD COLUMN b int;
DDL 3: 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 ジョブのみを検索し、DDL 履歴ジョブキュー内の最後の 10 件の結果を検索します。

TiDB は CBO (コストベースの最適化) をサポートしていますか? 「はい」の場合、どの程度ですか?

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

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

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

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

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

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

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

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 メモリパフォーマンスの調整を参照してください。