SQL Explorer - Database Autonomy Service - Alibaba Cloud ドキュメントセンター

前提条件

データベースインスタンスが DAS に追加され、接続ステータスが 通常の接続 になっています。
インスタンスで SQL Explorer and Audit が有効化されていること。詳細については、「SQL Explorer and Auditの有効化」をご参照ください。

仕組み

有効化されると、SQL Explorer はすべての DQL、DML、および DDL 操作を記録します。SQL Explorer は、CPU 使用率への影響を無視できるレベルに抑えつつ、この情報をデータベースカーネルから直接キャプチャします。

サポートされるデータベースとリージョン

DAS Enterprise Edition の各バージョンでサポートされるデータベースとリージョンについては、「エディションとサポートされる機能」をご参照ください。

注意事項

SQL Explorer の分析データと統計データは、SQL 詳細を除き、30 日間保持されます。
SQL Explorer の SQL 詳細データの保持期間は、DAS Enterprise Edition で設定された保持期間と同じです。
SQL Explorer and Audit を無効にしてもサービスに影響はありませんが、この操作により、この機能で保存されたデータはすべてクリアされます。この機能を無効にする前に、必要なデータをエクスポートしてローカルに保存してください。詳細については、「SQL Explorer and Auditの無効化」をご参照ください。
PolarDB-X 1.0 にアタッチされた ApsaraDB RDS for MySQL インスタンスで SQL ステートメントが実行されると、シャーディングにより、ApsaraDB RDS for MySQL インスタンスでは複数の SQL ログが生成されます。
データ移行は一時的な切断を引き起こす可能性があり、移行中に SQL Explorer のデータが失われることがあります。
データベースインスタンスの負荷が非常に高い場合、少数のレコードが失われる可能性があります。その結果、SQL Explorer からの増分データの統計が不正確になる場合があります。
パラメーターによって、記録される SQL ステートメントの最大長が決まります。この制限を超えるステートメントは、SQL Explorer には記録されません。データ収集中にプレフィックスが追加されるため、実際に記録される長さは、設定されたパラメーター値よりわずかに短くなります。
説明
- ApsaraDB RDS for MySQL および PolarDB for MySQL のバージョン 5.6 および 5.7 では、記録される長さは [loose_rds_audit_max_sql_size] パラメーターによって制御されます。
- ApsaraDB RDS for MySQL および PolarDB for MySQL のバージョン 8.0 では、記録される長さは [loose_rds_audit_log_event_buffer_size] パラメーターによって制御されます。
ApsaraDB RDS for PostgreSQL インスタンスで PgBouncer 接続プールが有効になっている場合、PgBouncer を介して実行される SQL ステートメントは SQL Explorer によって記録されません。

操作手順

にログインします。DASコンソール.
左側のナビゲーションウィンドウで、インスタンスモニター.
表示されるページで、管理するデータベースインスタンスを見つけ、インスタンスIDをクリックします。インスタンス詳細ページが表示されます。
左側のナビゲーションペインで、リクエスト分析 > SQL Explorer and Audit をクリックし、SQL Explorer タブをクリックします。
必要に応じて機能を選択します。

説明
時間範囲を選択する場合、終了時刻は開始時刻より後である必要があり、間隔は 1 日を超えることはできません。インスタンスで DAS Enterprise Edition を有効にすると、SQL Explorer のストレージ期間内の任意の日からデータをクエリできます。
- [時間範囲の表示]：時間範囲を選択して SQL Explorer の結果を表示します。選択した時間範囲内のすべての SQL 文の 実行期間の文布、実行時間、および 実行回数 を表示できます。また、完全なリクエスト統計 セクションですべての SQL 文の詳細を表示し、結果をエクスポートすることもできます。
  
  説明
  最大 1,000 件の SQL ログをエクスポートできます。より多くの SQL ログを取得したり、より長い時間範囲を対象としたりするには、監査機能を使用します。
- [比較リストの表示]: SQL Explorer の結果を比較する時点を選択します。すべての SQL 文の 実行期間の文布、実行時間、および 実行回数 の比較を表示できます。また、比較リストのリクエスト セクションで詳細な比較結果を表示することもできます。
- [ソース統計]: 時間範囲を選択して、SQL ソースの統計を表示します。選択した時間範囲内にあるすべての SQL 文のソース情報を表示できます。
- [SQL レビュー]: 選択した時間範囲とベースラインの時間範囲について、データベースインスタンスのワークロード分析を実行します。また、インスタンスで実行されている SQL ステートメントを詳細に分析し、インデックス最適化の提案、SQL 書き換えの提案、TOP SQL、新規 SQL、失敗した SQL、SQL 機能分析、実行に変更があった SQL、パフォーマンスが劣化した SQL、および TOP トラフィックテーブルを提供します。詳細については、「SQL レビュー」をご参照ください。
- [関連する SQL の特定]: 表示したいメトリクスを選択し、分析をクリックします。 1 ～ 5 分後、システムは、指定された時間範囲内で選択したメトリクスと傾向が最も一致する SQL ステートメントを識別して表示します。
重要
- ホットストレージとコールドストレージを使用する SQL Explorer and Audit では、システムは 7 日を超えたデータをコールドストレージに移動します。7 日を超えた SQL 詳細データを分析すると、システムはデータを再計算および分析するためのタスクを作成します。タスクの進捗状況と履歴は、タスクリスト ページで表示できます。
- 7 日より古い SQL Explorer and Audit データのクエリは、従量課金で課金されます。詳細については、「課金の詳細」をご参照ください。

結果

[実行期間の文布]：選択した時間範囲におけるすべての SQL ステートメントの実行時間分布を表示します。実行時間は 7 つの区間に分割され、1 分に 1 回計算されます：
- [0,1] ms は、実行時間が 0 ms から 1 ms (両端を含む) までの SQL 実行の割合を示します。
- (1,2] ms は、実行時間が 1 ms を超え 2 ms までの SQL 実行の割合を示します。
- (2,3] ms は、実行時間が 2 ms を超え 3 ms までの SQL 実行の割合を示します。
- (3,10] ms は、実行時間が 3 ms を超え 10 ms までの SQL 実行の割合を示します。
- (10,100] ms は、実行時間が 10 ms を超え 100 ms までの SQL 実行の割合を示します。
- (0.1,1] s は、実行時間が 0.1 秒を超え 1 秒までの SQL 実行の割合を示します。
- >1 s は、実行時間が 1 秒を超える SQL 実行の割合を示します。
説明
インスタンスの実行期間の文布が青に近いほど、その SQL パフォーマンスは良好です。オレンジと赤に近いほど、SQL パフォーマンスは悪化します。
[実行時間 (SQL RT)]: 選択した時間範囲内の SQL ステートメントの実行時間を表示します。
Full Request Statisticsは、選択した時間範囲内で、SQL ステートメントのタイプごとに SQL テキスト、所要時間の割合、平均実行時間、実行トレンドを表示します。

説明
実行時間割合とは、特定の SQL タイプの総実行時間が、すべての SQL タイプの総実行時間に占める割合のことです。実行時間割合が高い SQL タイプほど、MySQL インスタンスのリソースをより多く消費します。
[SQL ID]：[SQL ID] をクリックすると、そのステートメントのパフォーマンストレンドと SQL サンプルを表示できます。
[SQL サンプル]: SQL サンプル を使用して、どのクライアントアプリケーションが SQL ステートメントを発行したかを特定します。

説明
SQL サンプルは UTF-8 エンコーディングを使用します。

FAQ

Q: ️SQL Explorer の logout! ステートメントは、Full Request Statisticsセクションの ️SQL Explorer において何を意味しますか？

A: logout! は切断を示します。logout! イベントの期間は、最後のインタラクションと logout! が発生した時点との時間差です。この期間は、接続アイドル時間として解釈できます。ステータス 列のステータス [1158] はネットワーク切断を示し、これは次の原因によって引き起こされる可能性があります。

クライアント接続がタイムアウトした。
サーバーが予期せず切断された。
interactive_timeout または wait_timeout の期間を超えたため、サーバーが接続をリセットした。

Q: ️SQL Explorerソース統計 セクション (️SQL Explorer) で、パーセント記号 (%) が アクセスソース として表示されるのはなぜですか？

A：これは、ストアードプロシージャを使用した場合に発生することがあります。以下の例で、この動作を再現できます：

説明

この例では、ApsaraDB RDS for MySQL インスタンス、test_user という名前のテストアカウント、および testdb という名前のテストデータベースを使用します。

ApsaraDB RDS コンソールで、標準アカウントを作成し、データベースへのアクセス権を付与します。詳細については、「(非推奨、「手順1」にリダイレクト) データベースとアカウントの作成」をご参照ください。
テストアカウントを使用して、コマンドラインからデータベースインスタンスに接続します。詳細については、「(非推奨、「手順2」にリダイレクト) クライアントまたはCLIを使用したApsaraDB RDS for MySQLインスタンスへの接続」をご参照ください。

テストデータベースに切り替え、次のストアードプロシージャを作成します。

-- テストデータベースに切り替え
USE testdb;

-- ストアードプロシージャの作成
DELIMITER $$
DROP PROCEDURE IF EXISTS `das` $$
CREATE DEFINER=`test_user`@`%` PROCEDURE `das`()
BEGIN
SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID();
END $$
DELIMITER;

特権アカウントを使用してデータベースインスタンスに接続します。詳細については、「(非推奨、「手順2」にリダイレクト) クライアントまたはCLIを使用したApsaraDB RDS for MySQLインスタンスへの接続」をご参照ください。

ストアードプロシージャを呼び出します。

-- テストデータベースに切り替え
USE testdb;

-- ストアードプロシージャの呼び出し
CALL das();

+--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
| ID     | USER      | HOST   | DB     | COMMAND | TIME | STATE     | INFO                                                                    |
+--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
| 487818 | test_user | %:2065 | testdb | Query   |    0 | executing | SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID() |
+--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+

[ログ] セクションのデータベース名が SQL ステートメント内のものと異なるのはなぜですか？

Logs セクションのデータベース名はセッションコンテキストから取得されるのに対し、SQL ステートメント内の名前はユーザーが指定したもの（例：クロスデータベースクエリや動的 SQL）であり、設計上異なる場合があります。

SQL Explorer および Audit はデータベースパフォーマンスに影響を与えますか？

実際には、影響は極めて小さく、無視できるレベルです。

CPU およびメモリ： ほぼ検知できないほど極めて低い。
ストレージ： 影響なし。監査データはデータベースインスタンスのディスクではなく DAS 内に保存されます。
ネットワーク： 影響なし。
ディスクパフォーマンス： 影響なし。監査データは DAS 内に保存されるため、データベースインスタンスのディスクは関与しません。

Q：キャプチャされた SQL ステートメントが不完全なのはなぜですか？完全なステートメントを表示するにはどうすればよいですか？

A：これは、実行された SQL ステートメントが長すぎる場合に発生します。SQL Explorer で、対応するスレッド ID またはトランザクション ID を検索して、完全なステートメントを表示できます。

Q：ApsaraDB RDS for PostgreSQL インスタンスの監査ログで、一部の SQL ステートメントが「-」と表示されるのはなぜですか？

A：ApsaraDB RDS for PostgreSQL インスタンスの log_statement パラメーターが all に設定されている場合、クライアントから送信された空のステートメントも監査ログに記録されます。これらの空のステートメントは、監査ログの SQL ステートメント列に - として表示されますが、これは想定された動作です。空のステートメントを送信するロジックを最適化するために、クライアント側のソースコードを確認することを推奨します。

ベストプラクティス

低速SQLクエリのトラブルシューティング

API	説明
GetErrorRequestSample	指定された時間範囲内にデータベースインスタンスの SQL Explorer の結果から、失敗した SQL クエリのサンプルを最大 20 件まで非同期で照会します。
GetAsyncErrorRequestStatResult	データベースインスタンスの SQL Explorer の結果から、指定された SQL ステートメントの失敗した実行回数を非同期で取得します。
GetAsyncErrorRequestListByCode	データベースインスタンスの SQL Explorer の結果から、指定された MySQL エラーコードを生成したステートメントの SQL ID を非同期で照会します。
GetAsyncErrorRequestStatByCode	データベースインスタンスの SQL Explorer の結果から、MySQL エラーコードと各エラーコードに対応する SQL クエリの数を非同期で照会します。
GetFullRequestOriginStatByInstanceId	データベースインスタンスの SQL Explorer の結果から、アクセス元別に分類されたフルリクエストデータの統計を収集します。
GetFullRequestStatResultByInstanceId	データベースインスタンスの SQL Explorer の結果から、SQL ID 別に分類されたフルリクエストデータの統計を非同期で収集します。
GetFullRequestSampleByInstanceId	データベースインスタンスの SQL Explorer の結果から、SQL ID によって最大 20 件の SQL サンプルを照会します。
GetDasSQLLogHotData	データベースインスタンスの SQL Explorer and Audit について、過去 7 日間のホットストレージ内のデータの詳細を照会します。

Database Autonomy Service:SQL Explorer

前提条件

仕組み

サポートされるデータベースとリージョン

注意事項

操作手順

結果

FAQ

関連 API

ベストプラクティス