SQL 最適化機能の使用 - Database Autonomy Service - Alibaba Cloud ドキュメントセンター

Database Autonomy Service (DAS) は、診断結果、最適化の提案、および推定されるパフォーマンス向上を自動的に生成する SQL 最適化機能を提供します。これらの結果を確認して、提案を採用するかどうかを決定できます。このトピックでは、SQL 最適化機能の使用方法について説明します。

始める前に

データベースエンジンは次のいずれかである必要があります。
- RDS for MySQL
  
  説明
  RDS for MySQL の Basic Edition および Cluster Edition はサポートされていません。
- MyBase MySQL
- PolarDB for MySQL
  
  説明
  PolarDB for MySQL のシングルノードクラスター (旧スタンドアロンインスタンス) はサポートされていません。
- PolarDB-X 2.0
  
  説明
  メジャーバージョンが 5.4.13 で、マイナーバージョンが [16415631,16504348] の範囲にある PolarDB-X 2.0 インスタンスはサポートされていません。PolarDB-X 2.0 インスタンスのバージョンを表示するには、「インスタンスのバージョンの表示とアップグレード」をご参照ください。
- MongoDB
ターゲットインスタンスが DAS に接続されていること。詳細については、「インスタンスを DAS に接続する」をご参照ください。
ターゲットインスタンスのアクセスステータスが 正常なアクセス であること。

制限事項

X-Engine を使用するテーブルに対しては、SQL ステートメントの診断や最適化はできません。
PolarDB-X では、プリペアドステートメントを使用して SQL ステートメントを実行すると、スロークエリログにはステートメントテンプレート (例：select * from test where a = ? and b = ?) とバインドされたパラメーター (例：params: [1, 2]) が別々に記録されます。この形式は有効な SQL ステートメントとして直接実行できないため、元のステートメントに依存して分析や最適化を行う機能が制限される場合があります。

スローログからのビジュアル SQL 分析の作成

この機能は、複雑な SQL 実行フローを直感的で視覚的な形式で表示します。そのグラフィカルインターフェイスは、クエリの実行パス、ノードの効率、潜在的なボトルネックを明確に示し、SQL の最適化、コードレビュー、ヘルスチェック中に問題を迅速に特定し、修正するのに役立ちます。

重要

スローログ分析ページでの SQL 最適化は、RDS for MySQL 5.6、5.7、8.0 および PolarDB for MySQL 5.6、5.7、8.0 インスタンスでのみサポートされています。

DAS コンソールにログインします。
左側のナビゲーションウィンドウで、[インテリジェント O&M センター] > インスタンスモニター をクリックします。
ターゲットインスタンスを見つけ、インスタンス ID をクリックしてインスタンス詳細ページを開きます。
左側のナビゲーションウィンドウで、リクエスト分析 > 低速クエリログ をクリックします。
スロークエリログ分析 ページで、次の操作を行います。
- スロークエリログの統計 タブで、ターゲットの SQL テンプレートを見つけ、操作列の 最適化 をクリックします。
- スロークエリログの詳細 タブで、ターゲットの SQL ステートメントを見つけ、操作列の 最適化 をクリックします。
表示されたダイアログボックスで、スケジュールの作成 をクリックします。
実行ノードの種類を選択します。
- スタンバイノード (デフォルト)：現在のインスタンスのスタンバイノードです。このノードは主に、定型的なクエリ分析に使用されます。
- イベントノード：SQL ステートメントが実際に実行されたビジネスノードです。このノードは、トラブルシューティングや最適化に適しています。
作成の確認 をクリックして、可視化された実行計画 を作成します。

ビジュアル実行計画

重要

ビジュアル実行計画は、履歴レコードではなく、現在の実行ステータスを反映します。
ビジュアルマトリックスは、SQL ステートメントの複雑さに応じて調整されます。グラフに大量のコンテンツが含まれている場合は、ズームツールを使用して表示スケールを調整するか、リセットボタンをクリックして初期ビューに戻してください。

ビジュアル実行計画では、実行フローは下から上へ、左から右へと進みます。一番下のノードがクエリの開始点です。データはレイヤーごとに上方に流れ、最終的な結果が返されます。例：

ノードの色

効率的なノード (緑)：効率的なアクセス方法を示します。これには、system、const、eq_ref、ref、ref_or_null、index_merge が含まれます。
中程度の効率のノード (黄)：最適とは言えないアクセス方法を示します。これには、fulltext、unique_subquery、index_subquery、range が含まれます。
非効率なノード (赤)：非効率なアクセス方法であり、優先的に最適化すべきです。これには、all および index が含まれます。

ノードの詳細

上部：TABLE_SCAN や INDEX_SCAN などのノードタイプを表示します。
左側：コスト。CPU、メモリ、ディスク I/O などの要因に基づいてオプティマイザーが推定した相対的なメトリックです。
右側：返されると推定される行数。データ処理量を示します。

最適化の提案

クエリのパフォーマンスを大幅に向上させるには、赤色でマークされた非効率なノードを優先的に最適化してください。

用語集

用語	一般名	説明
QUERY_BLOCK	クエリブロック	SQL ステートメントのセマンティックユニット。独立した各クエリまたはサブクエリはクエリブロックを構成し、EXPLAIN の出力では `select_id` によって識別されます。
ATTACHED_SUBQUERIES	相関サブクエリ	`EXISTS`、`IN`、`ANY` などの述語を使用して `WHERE`、`HAVING`、または `ON` 句にアタッチされたサブクエリ。このタイプのサブクエリは、メインクエリとの間に論理的な依存関係があります。
CORRELATED_SUBQUERY	相関サブクエリ	外部クエリの列を参照するネストされたクエリ。実行中に外部コンテキストの値にバインドする必要があり、O(n²) の計算量になる可能性があります。
NON_CORRELATED_SUBQUERY	非相関サブクエリ	外部クエリとは独立して実行できる自己完結型のサブクエリ。オプティマイザーは通常、これを事前に計算し、定数としてマテリアライズします。
MATERIALIZED_FROM_SUBQUERY	マテリアライズされたサブクエリ	MySQL 5.6 以降で導入された最適化戦略。サブクエリの結果をメモリ内の一時テーブルに永続化し、多くの場合 `subqueryN` 形式の派生テーブルに関連付けられます。
OPTIMIZED_AWAY_SUBQUERIES	最適化によって削除されたサブクエリ	定数サブクエリのプッシュダウンなど、クエリリライト最適化の後に完全に削除されるサブクエリ。最終的な実行計画には表示されません。
QUERY_SPECIFICATIONS	クエリ仕様構造	SELECT リスト、FROM 句、フィルター条件など、クエリの構文要素を記述する完全なセマンティックユニット。
SELECT_LIST_SUBQUERIES	SELECT リストのサブクエリ	射影列 (SELECT フィールドリスト) に現れるスカラーサブクエリ。各反復で単一のスカラー値を返す必要があります。
INDEX_SCAN	インデックススキャン	B+ ツリーインデックスを使用するデータアクセスパターン。スキャンは順方向または逆方向に行うことができ、テーブルルックアップを伴う場合があります。
TABLE_SCAN	全表スキャン	オプティマイザーがクラスター化インデックスのすべてのページをスキャンするアクセス方法。これは、適切なインデックスが利用できない場合や、アクセスするデータの割合がしきい値を超えた場合に発生します。データ量が増加するにつれてパフォーマンスが低下します。
ORDERING_OPERATION	結果セットのソート	filesort などの明示的なソートアルゴリズムを使用して結果セットをソートする ORDER BY 操作。この操作は、メモリまたは一時ディスクファイルを使用する場合があります。
NESTED_LOOP	ネステッドループ結合	テーブル結合アルゴリズムの最も基本的な実装。外部テーブルの各行に対して、内部テーブルの一致する行を反復処理します。これは、結合述語が効果的なフィルタリングを提供する場合に効率的です。
DUPLICATES_REMOVAL	結果の重複排除	DISTINCT セマンティクスを実装する操作。基盤となる実装では、一時テーブルの一意なインデックスを使用したり、結果をソートしてからフィルタリングしたりする場合があります。コストはデータ分布の特性に依存します。
WINDOWING_OPERATION	ウィンドウ関数の計算	OVER() 句で定義されたデータウィンドウに対して実行される分析関数 (`ROW_NUMBER` や `RANK` など) の計算。これには、完全なデータセットのソートが必要になる場合があります。
TABLE	ベーステーブル参照	実行計画で直接アクセスされる物理ストレージオブジェクト。テーブル名、エイリアス、アクセス方法 (`const`、`system`、`range` など) などの情報が含まれます。

インスタンスセッションページからの SQL 最適化

重要

セルフマネージド MySQL、MongoDB、および RDS for PostgreSQL インスタンスは、インスタンスセッション ページでの SQL 最適化をサポートしていません。

DAS コンソールにログインします。
左側のナビゲーションウィンドウで、[インテリジェント O&M センター] > インスタンスモニター をクリックします。
ターゲットインスタンスを見つけ、インスタンス ID をクリックしてインスタンス詳細ページを開きます。
左側のナビゲーションウィンドウで、インスタンスセッション をクリックします。
インスタンスのセッション エリアで、最適化したいセッションを選択し、最適化 をクリックします。
表示された SQL 診断の最適化 ダイアログボックスで、SQL 診断結果を表示します。

提案を受け入れる場合は、右上隅の コピー をクリックし、最適化された SQL をデータベースクライアントまたは DMS に貼り付けて実行します。提案を受け入れない場合は、Cancel をクリックしてダイアログボックスを閉じます。

説明
DAS は、SQL ステートメントの複雑さ、テーブルのデータ量、およびデータベースの負荷に基づいて SQL ステートメントを診断します。診断には 20 秒以上かかる場合があります。その後、エンジンは診断結果、最適化の提案、および推定されるパフォーマンス向上を提供し、確認と採用を促します。

診断が完了すると、ページには元の SQL、実行計画 (select_type、type、rows などの列を含む)、診断結果 (行ストアインデックスの提案の DDL ステートメントとインデックスの詳細を含む)、最適化のメリット (例：「期待されるパフォーマンス向上：0.55 倍」および「最適化による効果が低い」)、およびステートメントの最適化の提案が表示されます。

SQL 診断履歴の表示

DAS コンソールにログインします。
左側のナビゲーションウィンドウで、[インテリジェント O&M センター] > インスタンスモニター をクリックします。
ターゲットインスタンスを見つけ、インスタンス ID をクリックしてインスタンス詳細ページを開きます。
左側のナビゲーションウィンドウで、診断履歴のリクエスト をクリックします。ここでは、SQL の内容、診断ステータス、時間、結果などの詳細を含む、インスタンスの SQL 診断履歴を表示できます。