すべてのプロダクト
Search

このプロダクト

    Database Autonomy Service:SQL の最適化

    ドキュメントセンター

    Database Autonomy Service:SQL の最適化

    最終更新日:Mar 04, 2026

    Database Autonomy Service (DAS) は、診断結果、最適化の提案、および期待されるパフォーマンス向上効果を自動的に生成する SQL 最適化機能を提供します。これらの結果をもとに、提案の適用可否を判断できます。本トピックでは、SQL 最適化機能の使用方法について説明します。

    始める前に

    • データベースエンジンは、

      • RDS for MySQL

        説明

        RDS for MySQL の Basic エディションおよび Cluster エディションはサポートされていません。

      • 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 に接続されている必要があります。詳細については、「インスタンス接続の概要」をご参照ください。

    • 宛先インスタンスのアクセス状態が 正常なアクセス である必要があります。

    制限事項

    • X-Engine テーブルを使用する SQL 文に対する診断および最適化はサポートされていません。

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

    スローログ分析ページでグラフィカルな実行計画を作成する

    この機能は、複雑な SQL 実行プロセスを視覚的に表現します。グラフィカルなインターフェイスにより、クエリの実行パス、各ノードの効率、および潜在的なパフォーマンスボトルネックを明確に把握できます。これにより、スロー SQL 文の最適化、リリース前のコードレビュー、および自己点検などのシナリオにおいて、問題を迅速に特定・解決できます。

    重要

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

    1. DAS コンソールにログインします。

    2. 左側のナビゲーションウィンドウで、インテリジェント O&M センター > インスタンスモニター をクリックします。

    3. 対象のインスタンスを見つけ、インスタンス ID をクリックしてインスタンス詳細ページを開きます。

    4. 左側のナビゲーションウィンドウで、リクエスト分析 > 低速クエリログ をクリックします。

    5. スロークエリログ分析 ページで：

      • スロークエリログの統計 タブで、対象の SQL テンプレートを見つけ、最適化 をクリックします（操作 列）。

      • スロークエリログの詳細 タブで、対象の SQL 文を見つけ、最適化 をクリックします（操作 列）。

    6. 表示されたダイアログボックスで、計画の作成 をクリックします。

    7. 実行ノードのタイプを選択します。

      • セカンダリノード（デフォルト）：現在のインスタンスのセカンダリノードであり、通常のクエリ分析に主に使用されます。

      • ソースノード：SQL 文が実行された業務ノードです。トラブルシューティングおよび最適化に適しています。

    8. 作成の確認 をクリックして、グラフィカルな実行計画 を作成します。

    グラフィカルな実行計画の詳細

    重要

    • グラフィカルな実行計画は、現在時刻における実行状態を反映したものであり、履歴記録ではありません。

    • 可視化マトリックスは 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 文の意味論的単位です。各独立したクエリまたはサブクエリが 1 つのクエリブロックを構成し、EXPLAIN 出力における select_id で識別されます。

    ATTACHED_SUBQUERIES

    添付サブクエリ

    WHERE、HAVING、またはON 句に、EXISTS、IN、またはANY などの述語を使用してアタッチされたサブクエリです。メインクエリとの論理的な依存関係があります。

    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 最適化を実行する

    重要

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

    1. DAS コンソールにログインします。

    2. 左側のナビゲーションウィンドウで、インテリジェント O&M センター > インスタンスモニター をクリックします。

    3. 対象のインスタンスを見つけ、インスタンス ID をクリックしてインスタンス詳細ページを開きます。

    4. 左側のナビゲーションウィンドウで、インスタンスセッション をクリックします。

    5. インスタンスのセッション エリアで、最適化対象のセッションを見つけ、最適化 をクリックします。

    6. 表示された SQL 診断の最適化 ダイアログボックスで、SQL 診断結果を確認します。

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

      説明

      DAS は、SQL 文の複雑さ、対応するテーブルのデータ量、およびデータベースの負荷に基づいて診断を行います。診断には 20 秒以上かかる場合があります。診断完了後、診断エンジンが結果、最適化の提案、および期待されるパフォーマンス向上効果を提供します。これらの結果をもとに、提案の適用可否を判断できます。

    SQL 診断履歴の表示

    1. DAS コンソールにログインします。

    2. 左側のナビゲーションウィンドウで、インテリジェント O&M センター > インスタンスモニター をクリックします。

    3. 対象のインスタンスを見つけ、インスタンス ID をクリックしてインスタンス詳細ページを開きます。

    4. 左側のナビゲーションウィンドウで、診断履歴のリクエスト をクリックして、現在のインスタンスの SQL 診断履歴を表示します。履歴には、SQL 内容、診断ステータス、診断時間、診断結果などの詳細が含まれます。