Database Autonomy Service:スロークエリログ

前提条件

データベースエンジンは PolarDB for MySQL です。

手順

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

2. 左側のナビゲーションウィンドウで、インスタンスモニター.

3. 表示されるページで、管理するデータベースインスタンスを見つけ、インスタンスIDをクリックします。 インスタンス詳細ページが表示されます。

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

5. スロークエリログ分析 タブで、時間範囲を選択して、スロークエリログの傾向、イベント配信、スロークエリログの統計、および スロークエリログの詳細 を表示します。

   • スロークエリログの傾向 グラフでは、特定の時点を選択して、その時点の スロークエリログの統計 と スロークエリログの詳細 を表示できます。

     説明

     スロー SQL ステートメントが長すぎて完全に表示されない場合は、ステートメントにマウスポインターを合わせると、ポップアップボックスに完全な SQL ステートメントが表示されます。

   • イベント配信 エリアでは、指定した期間内のスロークエリログイベントをクエリできます。イベントをクリックすると、その詳細が表示されます。

   • ノードID ドロップダウンリストから、各ノードのスローリクエスト数を確認できます。

   • 遅いログ統計 および 遅いログの詳細 タブで、 をクリックしてスロークエリログ情報をコンピューターに保存できます。

   • をクリックして OpenAPI Explorer コンソールに移動できます。現在選択および入力されているパラメーターは、API デバッグ用に自動的に引き継がれます。

   • スロークエリログの統計 エリアでは：

     • リストの上部で、フィルター条件を選択してデータをフィルタリングできます。利用可能なフィルター条件は、データベースエンジンによって異なります。

     • 対象の SQL テンプレートの [クエリ ID] 列にあるデータ ID をクリックすると、相関関係と、ユーザー分布、クライアント分布、メトリックの傾向を含む詳細なリストが表示されます。

     • 対象の SQL テンプレートの 操作 列で 最適化 をクリックします。表示された SQL 診断の最適化 ダイアログボックスで、SQL 診断結果を表示します。

       診断の提案を受け入れる場合は、ページ右上の コピー をクリックし、最適化された SQL ステートメントをデータベースクライアントまたは DMS に貼り付けて実行します。提案を受け入れない場合は、Cancel をクリックして診断を終了します。

       説明

       DAS は、SQL ステートメントの複雑さ、対応するテーブルのデータ量、およびデータベースのペイロードに基づいて SQL 診断を実行します。診断の提案が返されるまでに 20 秒以上かかる場合があります。診断が完了すると、診断エンジンは診断結果、最適化の提案、および期待される最適化効果を提示します。診断結果に基づいて提案を受け入れるかどうかを判断できます。

     • 対象の SQL テンプレートの 操作 列で スロットリングを実行してください。 をクリックします。SQL スロットリング ページで、スロットリングパラメーターを設定して、対象の SQL ステートメントにレート制限を適用します。詳細については、「SQL スロットリング」をご参照ください。

     • PolarDB for MySQL データベースインスタンスの場合、対象の SQL テンプレートの 操作 列で [IMCI] をクリックして、インメモリ列指向インデックス (IMCI) のドキュメントを表示します。

       説明

       • [IMCI] ボタンは、PolarDB for MySQL データベースインスタンスにインメモリ列指向インデックスノードがなく、スロークエリログの 最大実行時間 が 20 秒を超え、スキャンされた最大行数 が 200,000 を超える場合に表示されます。

       • データ量の多い複雑なクエリの場合、インメモリ列指向インデックス (IMCI) を使用してクエリのパフォーマンスを向上させることができます。

   • スロークエリログの詳細 エリアでも、対象の SQL ステートメントの 操作 列にある 最適化 と スロットリングを実行してください。 をクリックして、[SQL 診断の最適化]と [SQL スロットリング]を実行できます。

よくある質問

• Q：スロークエリログデータが表示されないのはなぜですか？

  A：スロークエリログ統計はリアルタイムの計算ウィンドウを使用して集計されるため、最新のデータは約 3 分の遅延で表示されます。また、次の点もご確認ください：

  • データベースインスタンスでスロークエリログ機能が有効になっており、しきい値が適切な値に設定されていること。

  • 選択した時間範囲内にスロークエリログが実際に生成されたこと。

  • 現在のアカウントが対象インスタンスに対する DAS のアクセス権限を持っていること。

• Q：一部のインスタンスが黄色でハイライト表示されるのはなぜですか？

  A：黄色のハイライトは、RAM ユーザーがそのインスタンスのデータアクセス権限を持っていないことを示します。この問題は、次のいずれかの方法で解決できます：

  • 管理者に連絡し、RAM ユーザーにインスタンスへのアクセス権限を付与してもらいます。

  • グローバルグループ権限の付与： DASGlobalGroupAdmin 権限を付与することを推奨します。これにより、RAM ユーザーは必要に応じてユーザーグループを作成し、アクセス権を持つすべてのインスタンスのデータを表示できるようになります。

• Q：クエリがデータを返すにもかかわらず、スロークエリログの Rows_sent が 0 と表示されるのはなぜですか？

  A：これは通常、アプリケーションがサーバーサイドカーソルモードを使用している場合に発生します。カーソルモードでは、1 つの SQL 文が次の 2 つの別々のフェーズで実行されます：

  • EXECUTE フェーズ： サーバーはクエリを実行して結果セットを生成しますが、データ行をすぐにクライアントに送信しません。列定義などのメタデータのみが返されます。

  • FETCH フェーズ： クライアントは FETCH コマンドを発行して、データ行をバッチで取得します。

  スロークエリログは EXECUTE フェーズの統計のみを記録します。このフェーズでは、MySQL はすでにデータをスキャンしていますが (そのため Rows_examined はゼロではありません)、後続の FETCH フェーズで行が配信されるため、クライアントにはまだ行が送信されていません。これが Rows_sent が 0 と記録される理由です。

  この動作を引き起こす一般的なシナリオ：

  • Java/JDBC： 接続 URL に useCursorFetch=true が含まれ、PreparedStatement.setFetchSize() が 0 より大きい値または Integer.MIN_VALUE に設定されている場合。

  • Python： アプリケーションが MySQLdb.cursors.SSCursor または pymysql.cursors.SSCursor を使用している場合。

  • ORM フレームワーク： 一部の ORM フレームワークは、大きな結果セットに対してデフォルトでストリーミングクエリを使用します。ストリーミングクエリは、内部でカーソルモードを使用します。

  これが原因であるかを確認するには、アプリケーションコードが fetchSize を設定しているか、またはストリーミングカーソルを使用しているかを確認してください。データベースで SHOW GLOBAL STATUS LIKE 'Com_stmt_fetch'; を実行して、FETCH リクエストが発行されているかどうかを確認することもできます。

• Q：スロークエリログに記録される実行完了時間が、SQL 文の実際の実行時間と異なるのはなぜですか？

  A：これは通常、実行された SQL 文がタイムゾーンを変更した場合に発生します。スロークエリログのタイムスタンプは、セッションレベル、データベースレベル、またはシステムレベルのタイムゾーンに基づいている場合があります。ログはデータベースレベルで設定されたタイムゾーンを使用するか、設定されていない場合はシステムレベルのタイムゾーンにフォールバックします。SQL 文がセッションレベルでタイムゾーンを変更すると、ログのタイムスタンプが正しく変換されず、不一致が生じることがあります。

関連ドキュメント

DAS の自律機能を利用することで、データベースインスタンス上のスロー SQL クエリを自動的に最適化できます。

• 自動 SQL 最適化

• 自動 SQL スロットリング