SQL チューニングの概要
このドキュメントでは、 TiDB Cloudで SQL パフォーマンスを調整する方法を紹介します。最高の SQL パフォーマンスを得るには、次の操作を実行できます。
- SQL パフォーマンスを調整します。クエリ ステートメントの分析、実行プランの最適化、完全なテーブル スキャンの最適化など、SQL パフォーマンスを最適化する方法は多数あります。
- スキーマ設計を最適化します。ビジネス ワークロードの種類によっては、トランザクションの競合やホットスポットを回避するためにスキーマを最適化する必要がある場合があります。
SQLパフォーマンスのチューニング
SQL ステートメントのパフォーマンスを向上させるには、次の原則を考慮してください。
- スキャンするデータの範囲を最小限に抑えます。常に、最小限の範囲のデータのみをスキャンし、すべてのデータをスキャンしないようにすることがベスト プラクティスです。
- 適切なインデックスを使用します。SQL ステートメントの
WHERE節の各列には、対応するインデックスがあることを確認してください。そうでない場合、WHERE節はテーブル全体をスキャンし、パフォーマンスが低下します。 - 適切な結合タイプを使用します。クエリ内の各テーブルのサイズと相関関係に応じて、適切な結合タイプを選択することが非常に重要です。通常、TiDB のコストベース オプティマイザーは最適な結合タイプを自動的に選択します。ただし、場合によっては結合タイプを手動で指定する必要があります。詳細については、 テーブル結合を使用するステートメントを説明する参照してください。
- 適切なstorageエンジンを使用します。ハイブリッド トランザクションおよび分析処理 (HTAP) ワークロードには、 TiFlashstorageエンジンを使用することをお勧めしますHTAP クエリ参照してください。
TiDB Cloud には、クラスター上の低速クエリを分析するのに役立つツールがいくつか用意されています。次のセクションでは、低速クエリを最適化するためのいくつかの方法について説明します。
診断タブのステートメントを使用する
TiDB Cloudコンソールの[診断]タブには[SQL ステートメント]サブタブがあります。このサブタブは、クラスター上のすべてのデータベースの SQL ステートメントの実行統計を収集します。これを使用して、合計または 1 回の実行で長い時間を消費する SQL ステートメントを識別して分析できます。
このサブタブでは、同じ構造を持つ SQL クエリ (クエリ パラメータが一致しない場合でも) が同じ SQL ステートメントにグループ化されることに注意してください。たとえば、 SELECT * FROM employee WHERE id IN (1, 2, 3)とselect * from EMPLOYEE where ID in (4, 5)どちらも同じ SQL ステートメントselect * from employee where id in (...)の一部です。
SQL ステートメントでいくつかの重要な情報を表示できます。
SQL テンプレート: SQL ダイジェスト、SQL テンプレート ID、現在表示されている時間範囲、実行プランの数、実行が行われるデータベースが含まれます。
実行プラン リスト: SQL ステートメントに複数の実行プランがある場合は、リストが表示されます。異なる実行プランを選択でき、選択した実行プランの詳細がリストの下部に表示されます。実行プランが 1 つしかない場合は、リストは表示されません。
実行プランの詳細: 選択した実行プランの詳細を表示します。各 SQL タイプの実行プランと対応する実行時間を複数の観点から収集し、詳細情報の取得に役立ちます実行計画参照してください。
関連する低速クエリ
ステートメントダッシュボードの情報に加えて、次のセクションで説明するように、 TiDB Cloudの SQL ベスト プラクティスもいくつかあります。
実行計画を確認する
EXPLAIN使用すると、コンパイル中に TiDB によって計算されたステートメントの実行プランを確認できます。つまり、TiDB は数百または数千の実行プランを推定し、消費するリソースが最も少なく、実行速度が最も速い最適な実行プランを選択します。
TiDB によって選択された実行プランが最適でない場合は、 EXPLAINまたはEXPLAIN ANALYZE使用して診断できます。
実行計画を最適化する
元のクエリ テキストをparserで解析し、基本的な有効性を検証した後、TiDB はまずクエリに対して論理的に同等の変更を加えます。詳細については、 SQL 論理最適化参照してください。
これらの等価性の変更により、論理実行プランでクエリを処理しやすくなります。等価性の変更後、TiDB は元のクエリと同等のクエリ プラン構造を取得し、データ分布と演算子の特定の実行オーバーヘッドに基づいて最終的な実行プランを取得します。詳細については、 SQL 物理最適化参照してください。
また、TiDB では、 実行プランキャッシュの準備で紹介されているように、 PREPAREステートメントを実行するときに実行プランの作成オーバーヘッドを削減するために、実行プラン キャッシュを有効にすることを選択できます。
フルテーブルスキャンの最適化
SQL クエリが遅くなる最も一般的な理由は、 SELECT文が完全なテーブル スキャンを実行するか、間違ったインデックスを使用することです。EXPLAIN またはEXPLAIN ANALYZEを使用して、クエリの実行プランを表示し、実行が遅い原因を特定できます。最適化に使用できるものは3つの方法あります。
- セカンダリインデックスを使用する
- カバーインデックスを使用する
- プライマリインデックスを使用する
DMLのベストプラクティス
主キーを選択する際の DDL のベスト プラクティス
インデックスのベストプラクティス
インデックス作成のベストプラクティスには、インデックスの作成と使用に関するベスト プラクティスが含まれています。
デフォルトではインデックス作成の速度は控えめですが、シナリオによってはインデックス作成プロセスを変数の変更倍高速化できます。
スキーマ設計を最適化する
SQL パフォーマンス チューニングを行ってもパフォーマンスが向上しない場合は、トランザクションの競合やホットスポットを回避するために、スキーマ設計とデータ読み取りモデルを確認する必要がある場合があります。
トランザクションの競合
トランザクションの競合を特定して解決する方法の詳細については、 ロック競合のトラブルシューティング参照してください。
ホットスポットの問題
キービジュアライザー使用してホットスポットの問題を分析できます。
Key Visualizer を使用すると、TiDB クラスターの使用パターンを分析し、トラフィックのホットスポットをトラブルシューティングできます。このページでは、TiDB クラスターのトラフィックの経時的な変化を視覚的に表示します。
Key Visualizer では次の情報を確認できます。まず、いくつか基本的な概念つを理解する必要があるかもしれません。
- 全体的なトラフィックを時間の経過とともに表示する大きなヒートマップ
- ヒートマップの座標に関する詳細情報
- 左側に表示される表や索引などの識別情報
Key Visualizer には4つの一般的なヒートマップの結果あります。
- 均等に分散された作業負荷：望ましい結果
- X軸（時間）に沿って明暗が交互に変化：ピーク時にリソースをチェックする必要がある
- Y軸に沿って明暗が交互に変化：生成されたホットスポットの集約度合いを確認する必要がある
- 明るい斜線：ビジネスモデルを確認する必要がある
X 軸と Y 軸が交互に明暗を繰り返すどちらの場合も、読み取りおよび書き込みの圧力に対処する必要があります。
SQL パフォーマンスの最適化の詳細については、「SQL FAQ」のSQL 最適化参照してください。