重要

TiDB v6.2 (DMR) のドキュメントを表示しています。PingCap は v6.2 のバグ修正を提供していません。バグは将来のリリースで修正される予定です。

一般的な目的では、TiDBデータベースの最新の安定バージョンを使用してください。
重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

インデックス問題の解決方法

一部のクエリの実行速度が期待に達していないことがわかった場合、オプティマイザはクエリを実行するために間違ったインデックスを選択する可能性があります。

最初に統計でテーブルのヘルス状態を表示してから、さまざまな健康状態に応じてこの問題を解決できます。

低健康状態

低ヘルス状態は、TiDB がANALYZEステートメントを長期間実行していないことを意味します。 ANALYZEコマンドを実行して、統計を更新できます。更新後、オプティマイザーがまだ間違ったインデックスを使用している場合は、次のセクションを参照してください。

ほぼ 100% の健康状態

ほぼ 100% の正常性状態は、 ANALYZEのステートメントが完了したばかりか、少し前に完了したことを示しています。この場合、間違ったインデックスの問題は、TiDB の行数の見積もりロジックに関連している可能性があります。

等価クエリの場合、原因はカウントミンスケッチである可能性があります。 Count-Min Sketch が原因であるかどうかを確認し、対応する解決策を講じることができます。

上記の原因が問題に当てはまらない場合は、 USE_INDEXまたはuse indexのオプティマイザー ヒントを使用してインデックスを強制選択できます (詳細については、 USE_INDEXを参照してください)。また、邪魔にならない方法でSQL計画管理を使用して、クエリの動作を変更することもできます。

その他の状況

前述の状況とは別に、不適切なインデックスの問題は、すべてのインデックスが適用できなくなるデータ更新によって引き起こされる場合もあります。このような場合、条件とデータ分布を分析して、新しいインデックスがクエリを高速化できるかどうかを確認する必要があります。その場合は、 ADD INDEXコマンドを実行して新しいインデックスを追加できます。