統計入門
TiDB は統計を使用してどのインデックスを選択するか決定します。
統計のバージョン
tidb_analyze_version
変数は、TiDB によって収集される統計を制御します。現在、 tidb_analyze_version = 1
とtidb_analyze_version = 2
2 つのバージョンの統計がサポートされています。
- TiDB Self-Hosted の場合、この変数のデフォルト値は v5.3.0 以降、
1
から2
に変更されます。 - TiDB Cloudの場合、この変数のデフォルト値は、v6.5.0 以降で
1
から2
に変更されます。 - クラスターが以前のバージョンからアップグレードされた場合、アップグレード後もデフォルト値
tidb_analyze_version
は変更されません。
バージョン 1 と比較すると、バージョン 2 の統計では、データ量が非常に多い場合にハッシュ衝突によって生じる潜在的な不正確さを回避します。また、ほとんどのシナリオで推定精度を維持します。
これら 2 つのバージョンには、TiDB に異なる情報が含まれています。
情報 | バージョン 1 | バージョン2 |
---|---|---|
表内の行の総数 | √ | √ |
カラム数最小スケッチ | √ | × |
インデックスカウント最小スケッチ | √ | × |
カラムトップN | √ | √(メンテナンス方法と精度が向上します) |
インデックストップN | √(メンテナンス精度が不十分だと不正確になる可能性があります) | √(メンテナンス方法と精度が向上します) |
カラムヒストグラム | √ | √ (ヒストグラムには Top-N 値は含まれません。) |
インデックスヒストグラム | √ | √ (ヒストグラム バケットには各バケット内の異なる値の数を記録し、ヒストグラムには上位 N の値は含まれません。) |
列内のNULL の数 | √ | √ |
インデックス内のNULL の数 | √ | √ |
列の平均長さ | √ | √ |
インデックスの平均長さ | √ | √ |
tidb_analyze_version = 2
場合、 ANALYZE
実行後にメモリオーバーフローが発生する場合は、 tidb_analyze_version = 1
を設定してバージョン 1 にフォールバックし、次のいずれかの操作を実行する必要があります。
ANALYZE
ステートメントを手動で実行する場合は、分析対象のすべてのテーブルを手動で分析します。SELECT DISTINCT(CONCAT('ANALYZE TABLE ', table_schema, '.', table_name, ';')) FROM information_schema.tables, mysql.stats_histograms WHERE stats_ver = 2 AND table_id = tidb_table_id;自動分析が有効になっているため、TiDB が
ANALYZE
ステートメントを自動的に実行する場合は、DROP STATS
ステートメントを生成する次のステートメントを実行します。SELECT DISTINCT(CONCAT('DROP STATS ', table_schema, '.', table_name, ';')) FROM information_schema.tables, mysql.stats_histograms WHERE stats_ver = 2 AND table_id = tidb_table_id;前のステートメントの結果が長すぎてコピーして貼り付けることができない場合は、結果を一時テキスト ファイルにエクスポートし、次のようにファイルから実行することができます。
SELECT DISTINCT ... INTO OUTFILE '/tmp/sql.txt'; mysql -h ${TiDB_IP} -u user -P ${TIDB_PORT} ... < '/tmp/sql.txt'
このドキュメントでは、ヒストグラム、Count-Min Sketch、Top-N について簡単に紹介し、統計の収集と管理について詳しく説明します。
ヒストグラム
ヒストグラムは、データの分布を大まかに表したものです。値の範囲全体を一連のバケットに分割し、バケットに含まれる値の数など、単純なデータを使用して各バケットを説明します。TiDB では、各テーブルの特定の列に対して等深度ヒストグラムが作成されます。等深度ヒストグラムを使用して、間隔クエリを推定できます。
ここで「等深度」とは、各バケットに入る値の数が可能な限り等しくなることを意味します。たとえば、特定のセット {1.6、1.9、1.9、2.0、2.4、2.6、2.7、2.7、2.8、2.9、3.4、3.5} に対して、4 つのバケットを生成するとします。等深度ヒストグラムは次のようになります。[1.6、1.9]、[2.0、2.6]、[2.7、2.8]、[2.9、3.5] の 4 つのバケットが含まれます。バケットの深さは 3 です。
ヒストグラムのバケット数の上限を決定するパラメータの詳細については、 手動収集を参照してください。バケット数が多いほどヒストグラムの精度は高くなりますが、精度が高くなるとメモリリソースの使用量が増大します。実際のシナリオに応じて、この数値を適切に調整できます。
カウントミニマムスケッチ
Count-Min Sketch はハッシュ構造です。等価クエリにa = 1
またはIN
クエリ (たとえばa in (1, 2, 3)
) が含まれる場合、TiDB はこのデータ構造を使用して推定を行います。
Count-Min Sketch はハッシュ構造であるため、ハッシュ衝突が発生する可能性があります。 EXPLAIN
文で、等価クエリの推定値が実際の値と大きく異なる場合、大きい値と小さい値が一緒にハッシュされていると考えられます。 この場合、ハッシュ衝突を回避するには、次のいずれかの方法を実行できます。
WITH NUM TOPN
パラメータを変更します。TiDB は高頻度 (上位 x) データを別々に保存し、その他のデータは Count-Min Sketch に保存します。したがって、大きい値と小さい値が一緒にハッシュされるのを防ぐには、WITH NUM TOPN
の値を増やすことができます。TiDB では、デフォルト値は 20 です。最大値は 1024 です。このパラメータの詳細については、 手動収集を参照してください。- 2 つのパラメータ
WITH NUM CMSKETCH DEPTH
とWITH NUM CMSKETCH WIDTH
を変更します。どちらもハッシュ バケットの数と衝突確率に影響します。実際のシナリオに応じて 2 つのパラメータの値を適切に増やすと、ハッシュ衝突の確率を下げることができますが、統計のメモリ使用量が高くなります。TiDB では、デフォルト値WITH NUM CMSKETCH DEPTH
は 5、デフォルト値WITH NUM CMSKETCH WIDTH
は 2048 です。2 つのパラメータの詳細については、 手動収集を参照してください。
上位Nの値
Top-N 値とは、列またはインデックス内で上位 N 個出現する値です。TiDB は、Top-N 値の値と出現を記録します。
統計を収集する
手動収集
現在、TiDB は完全なコレクションとして統計情報を収集します。統計を収集するには、 ANALYZE TABLE
ステートメントを実行できます。
注記:
- TiDB での
ANALYZE TABLE
の実行時間は、MySQL や InnoDB よりも長くなります。InnoDB では少数のページのみがサンプリングされますが、TiDB では包括的な統計セットが完全に再構築されます。MySQL 用に作成されたスクリプトでは、ANALYZE TABLE
短時間の操作であると誤って想定される可能性があります。- v7.5.0 以降、統計の高速分析機能 (
tidb_enable_fast_analyze
)と増分収集機能非推奨になりました。
次の構文を使用して完全なコレクションを実行できます。
TableNameList
内のすべてのテーブルの統計を収集するには:ANALYZE TABLE TableNameList [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE];WITH NUM BUCKETS
、生成されたヒストグラム内のバケットの最大数を指定します。WITH NUM TOPN
生成されるTOPN
の最大数を指定します。WITH NUM CMSKETCH DEPTH
CM スケッチの深さを指定します。WITH NUM CMSKETCH WIDTH
CM スケッチの幅を指定します。WITH NUM SAMPLES
サンプル数を指定します。WITH FLOAT_NUM SAMPLERATE
サンプリング レートを指定します。
WITH NUM SAMPLES
とWITH FLOAT_NUM SAMPLERATE
サンプルを収集する 2 つの異なるアルゴリズムに対応します。
WITH NUM SAMPLES
、TiDB のリザーバ サンプリング メソッドで実装されるサンプリング セットのサイズを指定します。テーブルが大きい場合、このメソッドを使用して統計を収集することはお勧めしません。リザーバ サンプリングの中間結果セットには冗長な結果が含まれるため、メモリなどのリソースに余分な負荷がかかります。WITH FLOAT_NUM SAMPLERATE
、v5.3.0 で導入されたサンプリング方法です。値の範囲が(0, 1]
の場合、このパラメータはサンプリング レートを指定します。これは、TiDB のベルヌーイ サンプリングの方法で実装されており、より大きなテーブルのサンプリングに適しており、収集効率とリソース使用率が向上します。
v5.3.0 より前の TiDB では、統計を収集するためにリザーバ サンプリング メソッドが使用されていました。v5.3.0 以降、TiDB バージョン 2 の統計では、デフォルトでベルヌーイ サンプリング メソッドが使用されて統計が収集されます。リザーバ サンプリング メソッドを再利用するには、 WITH NUM SAMPLES
ステートメントを使用できます。
現在のサンプリング レートは、適応アルゴリズムに基づいて計算されます。 SHOW STATS_META
を使用して表の行数を観察できる場合は、この行数を使用して 100,000 行に対応するサンプリング レートを計算できます。 この数を観察できない場合は、表のSHOW TABLE REGIONS
の結果のAPPROXIMATE_KEYS
列のすべての値の合計を別の基準として使用して、サンプリング レートを計算できます。
注記:
通常、
STATS_META
APPROXIMATE_KEYS
よりも信頼性が高いです。ただし、 TiDB Cloudコンソール ( サンプルデータのインポートを参照) からデータをインポートした後、STATS_META
の結果は0
なります。この状況に対処するには、STATS_META
の結果がAPPROXIMATE_KEYS
の結果よりもはるかに小さい場合に、APPROXIMATE_KEYS
使用してサンプリング レートを計算できます。
いくつかの列の統計を収集する
ほとんどの場合、SQL ステートメントを実行するときに、オプティマイザは一部の列 ( WHERE
、 JOIN
、 ORDER BY
、およびGROUP BY
ステートメントの列など) の統計のみを使用します。これらの列はPREDICATE COLUMNS
と呼ばれます。
テーブルに多数の列がある場合、すべての列の統計を収集すると、大きなオーバーヘッドが発生する可能性があります。オーバーヘッドを削減するには、オプティマイザーが使用する特定の列またはPREDICATE COLUMNS
のみの統計を収集できます。
注記:
- 一部の列の統計の収集は
tidb_analyze_version = 2
にのみ適用されます。- TiDB v7.2.0 以降、TiDB では
tidb_analyze_skip_column_types
システム変数が導入され、統計を収集するANALYZE
コマンドを実行するときに統計収集でスキップされる列の種類を示します。システム変数はtidb_analyze_version = 2
にのみ適用されます。
特定の列の統計を収集するには、次の構文を使用します。
ANALYZE TABLE TableName COLUMNS ColumnNameList [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE];構文では、
ColumnNameList
ターゲット列の名前リストを指定します。複数の列を指定する必要がある場合は、カンマ,
を使用して列名を区切ります。たとえば、ANALYZE table t columns a, b
。この構文では、特定のテーブルの特定の列の統計を収集するだけでなく、インデックス付き列とそのテーブルのすべてのインデックスの統計も同時に収集します。注記:
上記の構文は完全なコレクションです。たとえば、この構文を使用して列
a
とb
の統計を収集した後、列c
の統計も収集する場合は、追加の列c
のみをANALYZE TABLE t COLUMNS c
を使用して指定するのではなく、ANALYZE table t columns a, b, c
を使用して 3 つの列すべてを指定する必要があります。PREDICATE COLUMNS
の統計を収集するには、次の手順を実行します。TiDB が
PREDICATE COLUMNS
を収集できるようにするには、tidb_enable_column_tracking
システム変数の値をON
に設定します。設定後、TiDB は 300 秒ごとに
PREDICATE COLUMNS
情報をmysql.column_stats_usage
システム テーブルに書き込みます。ビジネスのクエリ パターンが比較的安定したら、次の構文を使用して
PREDICATE COLUMNS
の統計を収集します。ANALYZE TABLE TableName PREDICATE COLUMNS [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE];この構文は、特定のテーブル内の
PREDICATE COLUMNS
の統計を収集するだけでなく、そのテーブル内のインデックス付き列とすべてのインデックスの統計を同時に収集します。注記:
mysql.column_stats_usage
システム テーブルにそのテーブルのPREDICATE COLUMNS
レコードが含まれていない場合、上記の構文ではそのテーブル内のすべての列とすべてのインデックスの統計が収集されます。- この構文を使用して統計を収集した後、新しいタイプの SQL クエリを実行すると、オプティマイザーは一時的に古い列または疑似列の統計を使用し、次回から TiDB は使用された列の統計を収集します。
すべての列とインデックスの統計を収集するには、次の構文を使用します。
ANALYZE TABLE TableName ALL COLUMNS [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE];
ANALYZE
ステートメントの列構成 ( COLUMNS ColumnNameList
、 PREDICATE COLUMNS
、 ALL COLUMNS
を含む) を永続化する場合は、 tidb_persist_analyze_options
システム変数の値をON
に設定して構成の永続性を分析する機能を有効にします。ANALYZE 構成永続化機能を有効にした後、次の操作を実行します。
- TiDB が自動的に統計を収集する場合、または列構成を指定せずに
ANALYZE
ステートメントを実行して手動で統計を収集する場合、TiDB は統計収集に以前に保持された構成を引き続き使用します。 - 列構成を指定して
ANALYZE
ステートメントを手動で複数回実行すると、TiDB は最新のANALYZE
ステートメントで指定された新しい構成を使用して、以前に記録された永続的な構成を上書きします。
統計が収集されたPREDICATE COLUMNS
と列を検索するには、次の構文を使用します。
SHOW COLUMN_STATS_USAGE [ShowLikeOrWhere];
SHOW COLUMN_STATS_USAGE
ステートメントは次の 6 つの列を返します。
カラム名 | 説明 |
---|---|
Db_name | データベース名 |
Table_name | テーブル名 |
Partition_name | パーティション名 |
Column_name | 列名 |
Last_used_at | クエリの最適化で列統計が最後に使用された時刻 |
Last_analyzed_at | 列統計が最後に収集された時刻 |
次の例では、 ANALYZE TABLE t PREDICATE COLUMNS;
実行した後、 TiDB は列b
、 c
、およびd
の統計を収集します。ここで、列b
はPREDICATE COLUMN
であり、列c
とd
はインデックス列です。
SET GLOBAL tidb_enable_column_tracking = ON;
Query OK, 0 rows affected (0.00 sec)
CREATE TABLE t (a INT, b INT, c INT, d INT, INDEX idx_c_d(c, d));
Query OK, 0 rows affected (0.00 sec)
-- The optimizer uses the statistics on column b in this query.
SELECT * FROM t WHERE b > 1;
Empty set (0.00 sec)
-- After waiting for a period of time (100 * stats-lease), TiDB writes the collected `PREDICATE COLUMNS` to mysql.column_stats_usage.
-- Specify `last_used_at IS NOT NULL` to show the `PREDICATE COLUMNS` collected by TiDB.
SHOW COLUMN_STATS_USAGE WHERE db_name = 'test' AND table_name = 't' AND last_used_at IS NOT NULL;
+---------+------------+----------------+-------------+---------------------+------------------+
| Db_name | Table_name | Partition_name | Column_name | Last_used_at | Last_analyzed_at |
+---------+------------+----------------+-------------+---------------------+------------------+
| test | t | | b | 2022-01-05 17:21:33 | NULL |
+---------+------------+----------------+-------------+---------------------+------------------+
1 row in set (0.00 sec)
ANALYZE TABLE t PREDICATE COLUMNS;
Query OK, 0 rows affected, 1 warning (0.03 sec)
-- Specify `last_analyzed_at IS NOT NULL` to show the columns for which statistics have been collected.
SHOW COLUMN_STATS_USAGE WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL;
+---------+------------+----------------+-------------+---------------------+---------------------+
| Db_name | Table_name | Partition_name | Column_name | Last_used_at | Last_analyzed_at |
+---------+------------+----------------+-------------+---------------------+---------------------+
| test | t | | b | 2022-01-05 17:21:33 | 2022-01-05 17:23:06 |
| test | t | | c | NULL | 2022-01-05 17:23:06 |
| test | t | | d | NULL | 2022-01-05 17:23:06 |
+---------+------------+----------------+-------------+---------------------+---------------------+
3 rows in set (0.00 sec)
インデックスの統計を収集する
IndexNameList
in TableName
のすべてのインデックスの統計を収集するには、次の構文を使用します。
ANALYZE TABLE TableName INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE];
IndexNameList
が空の場合、この構文はTableName
内のすべてのインデックスの統計を収集します。
注記:
収集前後の統計情報の一貫性を確保するために、
tidb_analyze_version
が2
の場合、この構文はインデックスだけでなく、テーブル全体 (すべての列とインデックスを含む) の統計を収集します。
パーティションの統計を収集する
PartitionNameList
inTableName
のすべてのパーティションの統計を収集するには、次の構文を使用します。ANALYZE TABLE TableName PARTITION PartitionNameList [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE];PartitionNameList
inTableName
のすべてのパーティションのインデックス統計を収集するには、次の構文を使用します。ANALYZE TABLE TableName PARTITION PartitionNameList INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE];テーブル内の一部のパーティションのいくつかの列の統計を収集するだけが必要な場合は、次の構文を使用します。
ANALYZE TABLE TableName PARTITION PartitionNameList [COLUMNS ColumnNameList|PREDICATE COLUMNS|ALL COLUMNS] [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE];
動的プルーニングモードでパーティションテーブルの統計を収集する
動的剪定モードでパーティション化されたテーブルにアクセスすると、TiDB はテーブル レベルの統計 (GlobalStats と呼ばれる) を収集します。現在、GlobalStats はすべてのパーティションの統計から集計されます。動的プルーニング モードでは、パーティションテーブルの統計の更新によって GlobalStats の更新がトリガーされることがあります。
注記:
GlobalStats 更新がトリガーされ、
tidb_skip_missing_partition_stats
がOFF
場合:
- 一部のパーティションに統計がない場合 (分析されたことがない新しいパーティションなど)、GlobalStats の生成が中断され、パーティションに統計がないことを示す警告メッセージが表示されます。
- 特定のパーティションに一部の列の統計情報がない場合 (これらのパーティションで分析用に異なる列が指定されている場合)、これらの列の統計情報が集計されるときに GlobalStats の生成が中断され、特定のパーティションに一部の列の統計情報が存在しないことを示す警告メッセージが表示されます。
GlobalStats 更新がトリガーされ、
tidb_skip_missing_partition_stats
がON
場合:一部のパーティションのすべての列または一部の列の統計が欠落している場合、TiDB は GlobalStats を生成するときにこれらの欠落しているパーティションの統計をスキップするため、GlobalStats の生成には影響しません。
動的プルーニング モードでは、パーティションとテーブルの Analyze 構成は同じである必要があります。したがって、
ANALYZE TABLE TableName PARTITION PartitionNameList
ステートメントの後にCOLUMNS
構成を指定したり、WITH
の後にOPTIONS
構成を指定したりした場合、TiDB はそれらを無視し、警告を返します。
自動更新
INSERT
、 DELETE
、またはUPDATE
ステートメントの場合、TiDB は行数と変更された行数を自動的に更新します。TiDB はこの情報を定期的に保持し、更新サイクルは 20 * stats-lease
です。デフォルト値stats-lease
は3s
です。
関連するシステム変数
統計の自動更新に関連する 3 つのシステム変数は次のとおりです。
システム変数 | デフォルト値 | 説明 |
---|---|---|
tidb_auto_analyze_ratio | 0.5 | 自動更新の閾値 |
tidb_auto_analyze_start_time | 00:00 +0000 | TiDBが自動更新を実行できる1日の開始時刻 |
tidb_auto_analyze_end_time | 23:59 +0000 | TiDBが自動更新を実行できる1日の終了時刻 |
tidb_auto_analyze_partition_batch_size | 1 | パーティションテーブルを分析するときに TiDB が自動的に分析するパーティションの数 (つまり、パーティションテーブルの統計を自動的に更新するとき) |
テーブル内の変更された行数とtbl
の行の合計数の比率がtidb_auto_analyze_ratio
より大きく、現在の時刻がtidb_auto_analyze_start_time
からtidb_auto_analyze_end_time
間である場合、TiDB はバックグラウンドでANALYZE TABLE tbl
ステートメントを実行し、このテーブルの統計を自動的に更新します。
小さなテーブルで少量のデータを変更すると、頻繁に自動更新がトリガーされる状況を回避するために、テーブルの行数が 1000 未満の場合、そのようなデータ変更によって TiDB の自動更新がトリガーされません。 SHOW STATS_META
ステートメントを使用して、テーブル内の行数を表示できます。
注記:
現在、自動更新では、手動
ANALYZE
で入力した設定項目は記録されません。そのため、WITH
構文を使用してANALYZE
の収集動作を制御する場合は、統計情報を収集するためのスケジュールされたタスクを手動で設定する必要があります。
自動更新を無効にする
統計の自動更新によって過剰なリソースが消費され、オンライン アプリケーションの操作に影響が出る場合は、 tidb_enable_auto_analyze
システム変数を使用して無効にすることができます。
バックグラウンドのANALYZE
タスクを終了する
TiDB v6.0 以降、TiDB はKILL
ステートメントを使用してバックグラウンドで実行されているANALYZE
タスクを終了することをサポートしています。バックグラウンドで実行されているANALYZE
タスクが大量のリソースを消費し、アプリケーションに影響を与えていることがわかった場合は、次の手順を実行してANALYZE
タスクを終了できます。
次の SQL ステートメントを実行します。
SHOW ANALYZE STATUS結果の
instance
列目とprocess_id
列目を確認すると、TiDB インスタンスのアドレスとバックグラウンドANALYZE
タスクのタスクID
を取得できます。バックグラウンドで実行されている
ANALYZE
タスクを終了します。ANALYZE
タスクを終了するには、KILL TIDB ${id};
ステートメントを実行します。ここで、${id}
前の手順で取得したバックグラウンドANALYZE
タスクのID
です。
KILL
ステートメントの詳細については、 KILL
を参照してください。
ANALYZE
同時実行を制御する
ANALYZE
ステートメントを実行すると、システム変数を使用して同時実行性を調整し、システムへの影響を制御できます。
関連するシステム変数の関係を以下に示します。
tidb_build_stats_concurrency
、 tidb_build_sampling_stats_concurrency
、 tidb_analyze_partition_concurrency
、上の図に示すように、上流と下流の関係にあります。実際の合計同時実行数は、 tidb_build_stats_concurrency
* ( tidb_build_sampling_stats_concurrency
+ tidb_analyze_partition_concurrency
) です。これらの変数を変更するときは、それぞれの値を同時に考慮する必要があります。 tidb_analyze_partition_concurrency
、 tidb_build_sampling_stats_concurrency
、 tidb_build_stats_concurrency
の順に 1 つずつ調整し、システムへの影響を観察することをお勧めします。これら 3 つの変数の値が大きいほど、システムのリソース オーバーヘッドが大きくなります。
tidb_build_stats_concurrency
ANALYZE
ステートメントを実行すると、タスクは複数の小さなタスクに分割されます。各タスクは、1 つの列またはインデックスの統計情報のみを処理します。 tidb_build_stats_concurrency
変数を使用して、同時実行される小さなタスクの数を制御できます。デフォルト値は2
です。v7.4.0 以前のバージョンでは、デフォルト値は4
です。
tidb_build_sampling_stats_concurrency
通常の列を分析する場合、 tidb_build_sampling_stats_concurrency
使用してサンプリング タスクの実行の同時実行を制御できます。デフォルト値は2
です。
tidb_analyze_partition_concurrency
ANALYZE
ステートメントを実行する場合、 tidb_analyze_partition_concurrency
使用して、パーティションテーブルの統計の読み取りと書き込みの同時実行を制御できます。デフォルト値は2
です。v7.4.0 以前のバージョンの場合、デフォルト値は1
です。
tidb_distsql_scan_concurrency
通常の列を分析する場合、 tidb_distsql_scan_concurrency
変数を使用して、一度に読み取るリージョンの数を制御できます。デフォルト値は15
です。値を変更するとクエリのパフォーマンスに影響することに注意してください。値を慎重に調整してください。
tidb_index_serial_scan_concurrency
インデックス列を分析する場合、 tidb_index_serial_scan_concurrency
変数を使用して、一度に読み取るリージョンの数を制御できます。デフォルト値は1
です。値を変更するとクエリのパフォーマンスに影響することに注意してください。値を慎重に調整してください。
ANALYZE構成を永続化する
v5.4.0 以降、TiDB はいくつかのANALYZE
つの構成の永続化をサポートしています。この機能により、将来の統計収集に既存の構成を簡単に再利用できます。
永続性をサポートするANALYZE
構成は次のとおりです。
構成 | 対応するANALYZE構文 |
---|---|
ヒストグラムバケットの数 | バケット数 |
トップNの数 | 番号付きトップ |
サンプル数 | サンプル数 |
サンプリングレート | FLOATNUM SAMPLERATE 付き |
ANALYZE 列タイプ | AnalyzeColumnOption ::= ( 'すべての列' |
ANALYZE 列目 | ColumnNameList ::= 識別子 ( ',' 識別子 )* |
ANALYZE構成の永続性を有効にする
ANALYZE
構成の永続性機能は、デフォルトで無効になっています。この機能を有効にするには、システム変数tidb_persist_analyze_options
がON
であることを確認し、システム変数tidb_analyze_version
を2
に設定します。
この機能を使用すると、ステートメントを手動で実行するときに、 ANALYZE
ステートメントで指定された永続性設定を記録できます。記録されると、次回 TiDB が統計を自動的に更新するか、これらの設定を指定せずに手動で統計を収集するときに、TiDB は記録された設定に従って統計を収集します。
auto analyze操作に使用される特定のテーブルに保存されている構成を照会するには、次の SQL ステートメントを使用できます。
SELECT sample_num, sample_rate, buckets, topn, column_choice, column_ids FROM mysql.analyze_options opt JOIN information_schema.tables tbl ON opt.table_id = tbl.tidb_table_id WHERE tbl.table_schema = '{db_name}' AND tbl.table_name = '{table_name}';
TiDB は、最新のANALYZE
ステートメントで指定された新しい構成を使用して、以前に記録された永続構成を上書きします。たとえば、 ANALYZE TABLE t WITH 200 TOPN;
実行すると、 ANALYZE
ステートメントの上位 200 個の値が設定されます。続いてANALYZE TABLE t WITH 0.1 SAMPLERATE;
を実行すると、 ANALYZE TABLE t WITH 200 TOPN, 0.1 SAMPLERATE;
と同様に、上位 200 個の値と auto ANALYZE
ステートメントのサンプリング レート 0.1 の両方が設定されます。
ANALYZE構成の永続性を無効にする
ANALYZE
構成の永続性機能を無効にするには、 tidb_persist_analyze_options
システム変数をOFF
に設定します。 ANALYZE
構成の永続性機能はtidb_analyze_version = 1
には適用されないため、 tidb_analyze_version = 1
を設定することでもこの機能を無効にすることができます。
ANALYZE
構成の永続性機能を無効にした後、TiDB は永続化された構成レコードをクリアしません。したがって、この機能を再度有効にすると、TiDB は以前に記録された永続的な構成を使用して統計を収集し続けます。
注記:
ANALYZE
構成の永続性機能を再度有効にしたときに、以前に記録された永続性構成が最新のデータに適用できなくなった場合は、ANALYZE
ステートメントを手動で実行し、新しい永続性構成を指定する必要があります。
統計情報を収集するためのメモリ割り当て
TiDB v6.1.0 以降では、システム変数tidb_mem_quota_analyze
を使用して、TiDB で統計を収集するためのメモリクォータを制御できます。
適切な値tidb_mem_quota_analyze
を設定するには、クラスターのデータ サイズを考慮してください。デフォルトのサンプリング レートを使用する場合、主な考慮事項は、列の数、列値のサイズ、および TiDB のメモリ構成です。最大値と最小値を構成するときは、次の提案を考慮してください。
注記:
以下の提案は参考用です。実際のシナリオに基づいて値を設定する必要があります。
- 最小値: TiDB が最も多くの列を持つテーブルから統計を収集する場合の最大メモリ使用量よりも大きくする必要があります。おおよその目安: TiDB がデフォルト設定を使用して 20 列のテーブルから統計を収集する場合、最大メモリ使用量は約 800 MiB です。TiDB がデフォルト設定を使用して 160 列のテーブルから統計を収集する場合、最大メモリ使用量は約 5 GiB です。
- 最大値: TiDB が統計を収集していない場合は、使用可能なメモリよりも小さくする必要があります。
ANALYZE
状態のビュー
ANALYZE
ステートメントを実行するときに、次の SQL ステートメントを使用してANALYZE
の現在の状態を表示できます。
SHOW ANALYZE STATUS [ShowLikeOrWhere]
このステートメントはANALYZE
の状態を返します。 ShowLikeOrWhere
を使用して必要な情報をフィルタリングできます。
現在、 SHOW ANALYZE STATUS
ステートメントは次の 11 列を返します。
カラム名 | 説明 |
---|---|
テーブルスキーマ | データベース名 |
テーブル名 | テーブル名 |
パーティション名 | パーティション名 |
求人情報 | タスク情報。インデックスが分析される場合、この情報にはインデックス名が含まれます。 tidb_analyze_version =2 場合、この情報にはサンプル レートなどの構成項目が含まれます。 |
処理された行 | 分析された行数 |
開始時間 | タスクが開始される時間 |
州 | failed の状態running pending 含むfinished |
失敗理由 | タスクが失敗した理由。実行が成功した場合、値はNULL なります。 |
実例 | タスクを実行するTiDBインスタンス |
プロセスID | タスクを実行するプロセスID |
TiDB v6.1.0 以降では、 SHOW ANALYZE STATUS
ステートメントはクラスター レベルのタスクの表示をサポートします。TiDB を再起動した後でも、このステートメントを使用して再起動前のタスク レコードを表示できます。TiDB v6.1.0 より前では、 SHOW ANALYZE STATUS
ステートメントはインスタンス レベルのタスクのみを表示でき、タスク レコードは TiDB の再起動後にクリアされます。
SHOW ANALYZE STATUS
最新のタスク レコードのみを表示します。TiDB v6.1.0 以降では、システム テーブルmysql.analyze_jobs
を通じて過去 7 日間の履歴タスクを表示できます。
tidb_mem_quota_analyze
が設定され、TiDB のバックグラウンドで実行されている自動ANALYZE
タスクがこのしきい値を超えるメモリを使用すると、タスクは再試行されます。 SHOW ANALYZE STATUS
ステートメントの出力で、失敗したタスクと再試行されたタスクを確認できます。
tidb_max_auto_analyze_time
が 0 より大きく、TiDB のバックグラウンドで実行されている自動ANALYZE
タスクにこのしきい値を超える時間がかかる場合、タスクは終了します。
mysql> SHOW ANALYZE STATUS [ShowLikeOrWhere];
+--------------+------------+----------------+-------------------------------------------------------------------------------------------+----------------+---------------------+---------------------+----------+-------------------------------------------------------------------------------|
| Table_schema | Table_name | Partition_name | Job_info | Processed_rows | Start_time | End_time | State | Fail_reason |
+--------------+------------+----------------+-------------------------------------------------------------------------------------------+----------------+---------------------+---------------------+----------+-------------------------------------------------------------------------------|
| test | sbtest1 | | retry auto analyze table all columns with 100 topn, 0.055 samplerate | 2000000 | 2022-05-07 16:41:09 | 2022-05-07 16:41:20 | finished | NULL |
| test | sbtest1 | | auto analyze table all columns with 100 topn, 0.5 samplerate | 0 | 2022-05-07 16:40:50 | 2022-05-07 16:41:09 | failed | analyze panic due to memory quota exceeds, please try with smaller samplerate |
統計情報をビュー
次のステートメントを使用して統計ステータスを表示できます。
テーブルのメタデータ
SHOW STATS_META
ステートメントを使用すると、行の合計数と更新された行の数を表示できます。
SHOW STATS_META [ShowLikeOrWhere];
ShowLikeOrWhereOpt
の構文は次のとおりです。
現在、 SHOW STATS_META
ステートメントは次の 6 つの列を返します。
カラム名 | 説明 |
---|---|
db_name | データベース名 |
table_name | テーブル名 |
partition_name | パーティション名 |
update_time | 更新の時刻 |
modify_count | 変更された行の数 |
row_count | 行の総数 |
注記:
TiDB が DML ステートメントに従って合計行数と変更行数を自動的に更新すると、
update_time
も更新されます。したがって、update_time
必ずしもANALYZE
ステートメントが最後に実行された時刻を示すわけではありません。
テーブルの健全性状態
SHOW STATS_HEALTHY
ステートメントを使用すると、テーブルの正常性状態を確認し、統計の精度を大まかに見積もることができます。 modify_count
>= row_count
の場合、正常性状態は 0 です。 modify_count
< row_count
の場合、正常性状態は (1 - modify_count
/ row_count
) * 100 です。
構文は次のとおりです。
SHOW STATS_HEALTHY [ShowLikeOrWhere];
SHOW STATS_HEALTHY
のあらすじは、
現在、 SHOW STATS_HEALTHY
ステートメントは次の 4 つの列を返します。
カラム名 | 説明 |
---|---|
db_name | データベース名 |
table_name | テーブル名 |
partition_name | パーティション名 |
healthy | テーブルの健康状態 |
列のメタデータ
SHOW STATS_HISTOGRAMS
ステートメントを使用すると、すべての列の異なる値の数とNULL
の数を表示できます。
構文は次のとおりです。
SHOW STATS_HISTOGRAMS [ShowLikeOrWhere]
このステートメントは、すべての列の異なる値の数とNULL
の数を返します。 ShowLikeOrWhere
を使用して、必要な情報をフィルター処理できます。
現在、 SHOW STATS_HISTOGRAMS
ステートメントは次の 10 列を返します。
カラム名 | 説明 |
---|---|
db_name | データベース名 |
table_name | テーブル名 |
partition_name | パーティション名 |
column_name | 列名( is_index が0 の場合)またはインデックス名( is_index が1 の場合) |
is_index | インデックス列であるかどうか |
update_time | 更新の時刻 |
distinct_count | 異なる値の数 |
null_count | NULL の数 |
avg_col_size | 列の平均長さ |
相関 | 列と整数主キーのピアソン相関係数。2つの列間の関連の度合いを示します。 |
ヒストグラムのバケット
SHOW STATS_BUCKETS
ステートメントを使用して、ヒストグラムの各バケットを表示できます。
構文は次のとおりです。
SHOW STATS_BUCKETS [ShowLikeOrWhere]
図は以下のとおりです。
このステートメントは、すべてのバケットに関する情報を返します。 ShowLikeOrWhere
使用して、必要な情報をフィルタリングできます。
現在、 SHOW STATS_BUCKETS
ステートメントは次の 11 列を返します。
カラム名 | 説明 |
---|---|
db_name | データベース名 |
table_name | テーブル名 |
partition_name | パーティション名 |
column_name | 列名( is_index が0 の場合)またはインデックス名( is_index が1 の場合) |
is_index | インデックス列であるかどうか |
bucket_id | バケットのID |
count | バケットと前のバケットに含まれるすべての値の数 |
repeats | 最大値の発生回数 |
lower_bound | 最小値 |
upper_bound | 最大値 |
Ndv | バケット内の異なる値の数。このフィールドは非推奨であり、値が不正確なため常に0 表示されます。 |
トップN情報
SHOW STATS_TOPN
ステートメントを使用すると、TiDB によって現在収集されている Top-N 情報を表示できます。
構文は次のとおりです。
SHOW STATS_TOPN [ShowLikeOrWhere];
現在、 SHOW STATS_TOPN
ステートメントは次の 7 つの列を返します。
カラム名 | 説明 |
---|---|
db_name | データベース名 |
table_name | テーブル名 |
partition_name | パーティション名 |
column_name | 列名( is_index が0 の場合)またはインデックス名( is_index が1 の場合) |
is_index | インデックス列であるかどうか |
value | この列の値 |
count | 値が何回出現するか |
統計情報を削除
統計を削除するには、 DROP STATS
ステートメントを実行します。
DROP STATS TableName
上記のステートメントは、 TableName
のすべての統計を削除します。パーティションテーブルが指定されている場合、このステートメントは、このテーブル内のすべてのパーティションの統計と、動的プルーニング モードで生成された GlobalStats を削除します。
DROP STATS TableName PARTITION PartitionNameList;
上記のステートメントは、 PartitionNameList
内の指定されたパーティションの統計情報のみを削除します。
DROP STATS TableName GLOBAL;
上記のステートメントは、指定されたテーブルの動的プルーニング モードで生成された GlobalStats のみを削除します。
負荷統計
注記:
TiDB Cloudサーバーレスクラスターでは読み込み統計は利用できません。
デフォルトでは、列統計のサイズに応じて、TiDB は次のように異なる方法で統計をロードします。
- メモリを少量しか消費しない統計 (count、distinctCount、nullCount など) の場合、列データが更新されている限り、TiDB は対応する統計をメモリに自動的にロードし、SQL 最適化ステージで使用します。
- 大量のメモリを消費する統計 (ヒストグラム、TopN、Count-Min Sketch など) の場合、SQL 実行のパフォーマンスを確保するために、TiDB はオンデマンドで統計を非同期的にロードします。ヒストグラムを例に挙げると、TiDB は、オプティマイザがその列のヒストグラム統計を使用する場合にのみ、その列のヒストグラム統計をメモリにロードします。オンデマンドの非同期統計のロードは、SQL 実行のパフォーマンスには影響しませんが、SQL 最適化に不完全な統計を提供する可能性があります。
v5.4.0 以降、TiDB では統計の同期ロード機能が導入されています。この機能により、SQL ステートメントを実行するときに、TiDB は大規模な統計 (ヒストグラム、TopN、Count-Min Sketch 統計など) をメモリにメモリにロードできるようになり、SQL 最適化の統計の完全性が向上します。
この機能を有効にするには、 tidb_stats_load_sync_wait
システム変数の値を、SQL 最適化が完全な列統計を同期的にロードするまで待機できる最大タイムアウト (ミリ秒単位) に設定します。この変数のデフォルト値は100
で、この機能が有効であることを示します。
統計の同期ロード機能を有効にした後、 tidb_stats_load_pseudo_timeout
システム変数の値を変更することで、SQL 最適化の待機時間がタイムアウトに達したときの TiDB の動作を制御できます。この変数のデフォルト値はON
で、タイムアウト後、SQL 最適化プロセスはどの列でもヒストグラム、TopN、または CMSketch 統計を使用しないことを示します。この変数がOFF
に設定されている場合、タイムアウト後、SQL 実行は失敗します。
輸入と輸出の統計
注記:
このセクションはTiDB Cloudには適用されません。
輸出統計
統計をエクスポートするためのインターフェースは次のとおりです。
${db_name}
データベース内の${table_name}
テーブルの JSON 形式の統計を取得するには:http://${tidb-server-ip}:${tidb-server-status-port}/stats/dump/${db_name}/${table_name}例えば:
curl -s http://127.0.0.1:10080/stats/dump/test/t1 -o /tmp/t1.json特定の時間における
${db_name}
データベース内の${table_name}
テーブルの JSON 形式の統計を取得するには:http://${tidb-server-ip}:${tidb-server-status-port}/stats/dump/${db_name}/${table_name}/${yyyyMMddHHmmss}
輸入統計
注記:
MySQL クライアントを起動するときは、
--local-infile=1
オプションを使用します。
通常、インポートされた統計は、エクスポート インターフェイスを使用して取得された JSON ファイルを参照します。
構文:
LOAD STATS 'file_name'
file_name
はインポートする統計のファイル名です。
ロック統計
v6.5.0 以降、TiDB は統計のロックをサポートしています。テーブルまたはパーティションの統計がロックされると、テーブルの統計は変更できなくなり、テーブルに対してANALYZE
ステートメントを実行することもできなくなります。例:
テーブルt
を作成し、そこにデータを挿入します。テーブルt
の統計がロックされていない場合、 ANALYZE
ステートメントは正常に実行できます。
mysql> CREATE TABLE t(a INT, b INT);
Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO t VALUES (1,2), (3,4), (5,6), (7,8);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> ANALYZE TABLE t;
Query OK, 0 rows affected, 1 warning (0.02 sec)
mysql> SHOW WARNINGS;
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1105 | Analyze use auto adjusted sample rate 1.000000 for table test.t, reason to use this rate is "Row count in stats_meta is much smaller compared with the row count got by PD, use min(1, 15000/4) as the sample-rate=1" |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
テーブルt
の統計をロックし、 ANALYZE
を実行します。警告メッセージは、 ANALYZE
ステートメントがテーブルt
をスキップしたことを示します。
mysql> LOCK STATS t;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW STATS_LOCKED;
+---------+------------+----------------+--------+
| Db_name | Table_name | Partition_name | Status |
+---------+------------+----------------+--------+
| test | t | | locked |
+---------+------------+----------------+--------+
1 row in set (0.01 sec)
mysql> ANALYZE TABLE t;
Query OK, 0 rows affected, 2 warnings (0.00 sec)
mysql> SHOW WARNINGS;
+---------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+---------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1105 | Analyze use auto adjusted sample rate 1.000000 for table test.t, reason to use this rate is "use min(1, 110000/8) as the sample-rate=1" |
| Warning | 1105 | skip analyze locked table: test.t |
+---------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
表t
およびANALYZE
の統計のロックを解除すると、再度正常に実行できます。
mysql> UNLOCK STATS t;
Query OK, 0 rows affected (0.01 sec)
mysql> ANALYZE TABLE t;
Query OK, 0 rows affected, 1 warning (0.03 sec)
mysql> SHOW WARNINGS;
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1105 | Analyze use auto adjusted sample rate 1.000000 for table test.t, reason to use this rate is "use min(1, 110000/8) as the sample-rate=1" |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
さらに、 LOCK STATS
使用してパーティションの統計をロックすることもできます。次に例を示します。
パーティション テーブルt
を作成し、そこにデータを挿入します。パーティションp1
の統計がロックされていない場合、 ANALYZE
ステートメントは正常に実行できます。
mysql> CREATE TABLE t(a INT, b INT) PARTITION BY RANGE (a) (PARTITION p0 VALUES LESS THAN (10), PARTITION p1 VALUES LESS THAN (20), PARTITION p2 VALUES LESS THAN (30));
Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO t VALUES (1,2), (3,4), (5,6), (7,8);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> ANALYZE TABLE t;
Query OK, 0 rows affected, 6 warning (0.02 sec)
mysql> SHOW WARNINGS;
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Warning | 1105 | disable dynamic pruning due to t has no global stats |
| Note | 1105 | Analyze use auto adjusted sample rate 1.000000 for table test.t's partition p0, reason to use this rate is "Row count in stats_meta is much smaller compared with the row count got by PD, use min(1, 15000/4) as the sample-rate=1" |
| Warning | 1105 | disable dynamic pruning due to t has no global stats |
| Note | 1105 | Analyze use auto adjusted sample rate 1.000000 for table test.t's partition p1, reason to use this rate is "TiDB assumes that the table is empty, use sample-rate=1" |
| Warning | 1105 | disable dynamic pruning due to t has no global stats |
| Note | 1105 | Analyze use auto adjusted sample rate 1.000000 for table test.t's partition p2, reason to use this rate is "TiDB assumes that the table is empty, use sample-rate=1" |
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
6 rows in set (0.01 sec)
パーティションp1
の統計をロックし、 ANALYZE
を実行します。警告メッセージは、 ANALYZE
ステートメントがパーティションp1
をスキップしたことを示します。
mysql> LOCK STATS t PARTITION p1;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW STATS_LOCKED;
+---------+------------+----------------+--------+
| Db_name | Table_name | Partition_name | Status |
+---------+------------+----------------+--------+
| test | t | p1 | locked |
+---------+------------+----------------+--------+
1 row in set (0.00 sec)
mysql> ANALYZE TABLE t PARTITION p1;
Query OK, 0 rows affected, 2 warnings (0.01 sec)
mysql> SHOW WARNINGS;
+---------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1105 | Analyze use auto adjusted sample rate 1.000000 for table test.t's partition p1, reason to use this rate is "TiDB assumes that the table is empty, use sample-rate=1" |
| Warning | 1105 | skip analyze locked table: test.t partition (p1) |
+---------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
パーティションp1
とANALYZE
の統計情報のロック解除を再度正常に実行できます。
mysql> UNLOCK STATS t PARTITION p1;
Query OK, 0 rows affected (0.00 sec)
mysql> ANALYZE TABLE t PARTITION p1;
Query OK, 0 rows affected, 1 warning (0.01 sec)
mysql> SHOW WARNINGS;
+-------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1105 | Analyze use auto adjusted sample rate 1.000000 for table test.t's partition p1, reason to use this rate is "TiDB assumes that the table is empty, use sample-rate=1" |
+-------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
統計情報のロックの動作
- パーティションテーブルの統計をロックすると、パーティションテーブルのすべてのパーティションの統計がロックされます。
- テーブルまたはパーティションを切り捨てると、テーブルまたはパーティションの統計ロックが解除されます。
次の表は、統計のロックの動作を示しています。
テーブル全体を削除する | テーブル全体を切り捨てる | パーティションを切り捨てる | 新しいパーティションを作成する | パーティションを削除する | パーティションを再編成する | パーティションを交換する | |
---|---|---|---|---|---|---|---|
パーティションテーブルがロックされている | ロックが無効です | TiDBは古いテーブルを削除するためロックは無効になり、ロック情報も削除されます。 | / | / | / | / | / |
パーティションテーブルとテーブル全体がロックされている | ロックが無効です | TiDBは古いテーブルを削除するためロックは無効になり、ロック情報も削除されます。 | 古いパーティションのロック情報は無効であり、新しいパーティションは自動的にロックされます | 新しいパーティションは自動的にロックされます | 削除されたパーティションのロック情報はクリアされ、テーブル全体のロックは引き続き有効になります。 | 削除されたパーティションのロック情報はクリアされ、新しいパーティションは自動的にロックされます | ロック情報は交換されたテーブルに転送され、新しいパーティションは自動的にロックされます。 |
パーティションテーブルで、一部のパーティションのみがロックされている | ロックが無効です | TiDBは古いテーブルを削除するためロックは無効になり、ロック情報も削除されます。 | TiDBは古いテーブルを削除するためロックは無効になり、ロック情報も削除されます。 | / | 削除されたパーティションのロック情報はクリアされます | 削除されたパーティションのロック情報はクリアされます | ロック情報は交換テーブルに転送される |