SQL チューニングの概要

このドキュメントでは、 TiDB Cloudで SQL パフォーマンスを調整する方法を紹介します。最高の SQL パフォーマンスを得るには、次のことを実行できます。

  • SQL パフォーマンスを調整します。クエリ ステートメントの分析、実行計画の最適化、全テーブル スキャンの最適化など、SQL パフォーマンスを最適化する方法は多数あります。
  • スキーマ設計を最適化します。ビジネス ワークロードの種類によっては、トランザクションの競合やホットスポットを回避するためにスキーマを最適化する必要がある場合があります。

SQL パフォーマンスの調整

SQL ステートメントのパフォーマンスを向上させるには、次の原則を考慮してください。

  • スキャンしたデータの範囲を最小限に抑えます。最小限の範囲のデータのみをスキャンし、すべてのデータをスキャンしないようにすることが常にベスト プラクティスです。
  • 適切な索引を使用してください。 SQL ステートメントのWHERE句の各列について、対応するインデックスがあることを確認してください。そうしないと、 WHERE句がテーブル全体をスキャンし、パフォーマンスが低下します。
  • 適切な結合タイプを使用してください。クエリ内の各テーブルのサイズと相関関係に応じて、適切な結合タイプを選択することが非常に重要です。一般に、TiDB のコストベースのオプティマイザは、最適な Join タイプを自動的に選択します。ただし、場合によっては、結合タイプを手動で指定する必要があります。詳細については、 テーブル結合を使用するステートメントの説明を参照してください。
  • 適切なストレージ エンジンを使用します。 Hybrid Transactional and Analytical Processing (HTAP) ワークロードには、TiFlash ストレージ エンジンを使用することをお勧めします。 HTAP クエリを参照してください。

TiDB Cloudは、クラスター上の低速クエリを分析するのに役立ついくつかのツールを提供します。次のセクションでは、スロー クエリを最適化するためのいくつかのアプローチについて説明します。

[診断] タブでステートメントを使用する

TiDB Cloudコンソールには、[診断] タブに [ステートメント] サブタブがあります。クラスター上のすべてのデータベースの 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 (...)の一部です。

Statementでいくつかの重要な情報を確認できます。

  • SQL ステートメントの概要: SQL ダイジェスト、SQL テンプレート ID、現在表示されている時間範囲、実行計画の数、および実行が行われるデータベースを含みます。
  • 実行計画リスト: SQL ステートメントに複数の実行計画がある場合、リストが表示されます。さまざまな実行計画を選択でき、選択した実行計画の詳細がリストの下部に表示されます。実行計画が 1 つしかない場合、リストは表示されません。
  • 実行計画の詳細: 選択した実行計画の詳細を表示します。このような SQL タイプの実行計画と対応する実行時間をいくつかの観点から収集して、より多くの情報を取得できるようにします。 実行計画の詳細を参照してください (下の画像の領域 3)。

Details

Statementダッシュボードの情報に加えて、次のセクションで説明するように、 TiDB Cloudの SQL ベスト プラクティスもいくつかあります。

実行計画を確認する

EXPLAINを使用して、コンパイル中に TiDB によって計算されたステートメントの実行計画を確認できます。つまり、TiDB は数百または数千の実行計画を推定し、リソースの消費が最も少なく、実行速度が最も速い最適な実行計画を選択します。

TiDB によって選択された実行計画が最適でない場合は、 EXPLAINまたはEXPLAIN ANALYZEを使用して診断できます。

実行計画を最適化する

元のクエリ テキストをparserで解析し、基本的な有効性を検証した後、TiDB は最初に論理的に同等の変更をクエリに加えます。詳細については、 SQL 論理最適化を参照してください。

これらの等価性の変更により、クエリは論理実行プランで処理しやすくなります。同等性が変化した後、TiDB は元のクエリと同等のクエリ プラン構造を取得し、データ分散とオペレーターの特定の実行オーバーヘッドに基づいて最終的な実行プランを取得します。詳細については、 SQL 物理最適化を参照してください。

また、TiDB は、実行計画キャッシュを有効にして、 PREPAREステートメントを実行するときの実行計画の作成オーバーヘッドを削減することもできます ( 実行計画キャッシュの準備で紹介)。

テーブル全体のスキャンを最適化する

SQL クエリが遅くなる最も一般的な理由は、 SELECTステートメントが全テーブル スキャンを実行するか、不適切なインデックスを使用することです。 EXPLAINまたはEXPLAIN ANALYZE を使用して、クエリの実行計画を表示し、実行が遅い原因を突き止めることができます。最適化に使用できるものは3つの方法あります。

  • セカンダリ インデックスを使用する
  • カバリングインデックスを使用
  • プライマリ インデックスを使用

DML のベスト プラクティス

DML のベスト プラクティスを参照してください。

主キーを選択する際の DDL のベスト プラクティス

主キーを選択する際に従うべきガイドラインを参照してください。

インデックスのベスト プラクティス

インデックス作成のベスト プラクティスには、インデックスの作成とインデックスの使用に関するベスト プラクティスが含まれています。

インデックス作成の速度はデフォルトでは控えめであり、一部のシナリオではインデックス作成プロセスを変数の変更倍高速化できます。

スキーマ設計の最適化

それでも SQL パフォーマンス チューニングに基づいてパフォーマンスを向上できない場合は、スキーマの設計とデータ読み取りモデルを確認して、トランザクションの競合とホットスポットを回避する必要があります。

トランザクションの競合

トランザクションの競合を見つけて解決する方法の詳細については、 ロック競合のトラブルシューティングを参照してください。

ホットスポットの問題

キー ビジュアライザーを使用して、ホットスポットの問題を分析できます。

Key Visualizer を使用して、TiDB クラスターの使用パターンを分析し、トラフィックのホットスポットをトラブルシューティングできます。このページでは、TiDB クラスターのトラフィックを経時的に視覚的に表現しています。

Key Visualizer で次の情報を確認できます。最初にいくつかの基本概念を理解する必要があるかもしれません。

  • 時間の経過に伴う全体的なトラフィックを示す大きなヒート マップ
  • ヒートマップの座標に関する詳細情報
  • 左側に表示される表や索引などの識別情報

Key Visualizer には4 つの一般的なヒート マップの結果があります。

  • 均等に分散されたワークロード: 望ましい結果
  • X軸(時間)に沿って明暗が交互に変化:ピーク時にリソースを確認する必要があります
  • Y 軸に沿って明暗が交互に変化: 生成されたホットスポットの凝集度を確認する必要があります
  • 明るい斜線:ビジネスモデルの確認が必要

X 軸と Y 軸が交互に明るい部分と暗い部分のどちらの場合でも、読み取りと書き込みの圧力に対処する必要があります。

SQL パフォーマンスの最適化の詳細については、SQL FAQ のSQL の最適化を参照してください。

エコシステム
TiDB
TiKV
TiSpark
Chaos Mesh
© 2022 PingCAP. All Rights Reserved.