同じビジネスシナリオでも、アーキテクチャの選択やインデックスの設計などの要因がクエリのパフォーマンスに大きな影響を与える可能性があります。非効率な設計は、多くの場合、スロー SQL ステートメント (実行時間が長いクエリ) につながります。このトピックでは、スロー SQL ステートメントの一般的な原因と解決策について説明します。
SQL 例外
-
原因と現象
SQL 例外は、非効率なテーブルスキーマ設計、インデックスの欠落、スキャンする行数が多すぎることなど、多くの要因が原因で発生する可能性があります。
SQL エクスプローラー ページでは、低速 SQL ステートメントの実行時間と実行頻度を確認できます。
-
解決策
ビジネス要件に基づいて SQL ステートメントを最適化してください。詳細については、「SQL 最適化」をご参照ください。
インスタンスのボトルネック
-
原因と現象
インスタンスでパフォーマンスのボトルネックが発生する理由はいくつかあります。
-
インスタンスをスケールアップせずにビジネスボリュームが継続的に増加しています。
-
ハードウェアの老朽化によってパフォーマンスが低下します。
-
データ量の絶え間ない増加とデータ構造の変化により、以前は高速だった SQL ステートメントが遅くなることがあります。
コンソールのモニターとアラーム ページに移動し、標準モニタリング タブをクリックして、リソースモニター セクションでインスタンスのリソース使用量を確認できます。リソース使用率が 100% に近い場合、インスタンスがパフォーマンスのボトルネックに達している可能性があります。
-
-
解決策
ベンチマークテストを実行することは、インスタンスでボトルネックが発生しているかどうかを判断するための良い方法です。たとえば、SysBench を使用してベンチマークテストを実行できます。複雑なシナリオにおける 1 秒あたりのクエリ数 (QPS) と 1 秒あたりのトランザクション数 (TPS) がベンチマーク値を超えることはほとんどありません。
インスタンスでボトルネックが発生していることを確認した場合は、インスタンス仕様をアップグレードすることを推奨します。詳細については、「インスタンス仕様の変更」をご参照ください。
バージョンのアップグレード
-
原因と現象
インスタンスのバージョンをアップグレードすると、SQL 実行計画が変更される可能性があります。実行計画の結合タイプは、効率的なものから順に、system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > all となります。詳細については、「MySQL の公式ドキュメント」をご参照ください。
SQL リクエストの結合タイプが
rangeまたはindexに変更された後に速度が低下し、アプリケーションがリクエストを繰り返し再試行すると、並列 SQL クエリの数が増加する可能性があります。これにより、アプリケーションスレッドの解放が遅くなり、接続プールが枯渇してサービス全体に影響を与える可能性があります。コンソールのモニターとアラームページに移動し、標準モニタリングタブをクリックして、リソースモニターセクションでインスタンスの接続数を確認できます。
-
解決策
実行計画を分析してインデックスの使用状況とスキャンされた行数を確認し、クエリの効率を推定します。SQL ステートメントを再構築するか、インデックスを調整して、クエリのパフォーマンスを向上させてください。詳細については、「SQL 最適化」をご参照ください。
不適切なパラメータ設定
-
原因と現象
[innodb_buffer_pool_instances] や [join_buffer_size] などのパラメーターの設定が不適切な場合、パフォーマンスが低下する可能性があります。
コンソールのパラメーターの設定ページに移動し、変更履歴タブをクリックして、インスタンスのパラメーター変更履歴を表示できます。
-
解決策
ビジネスシナリオに合わせて関連するパラメーターを調整してください。
キャッシュスタンピード
-
原因と現象
キャッシュは多数のクエリを処理できますが、キャッシュヒット率が 100% になる保証はありません。キャッシュスタンピードは、複数のキャッシュエントリが同時に期限切れになり、大量のクエリがデータベースにルーティングされることでパフォーマンスが低下する場合に発生します。
コンソールで モニターとアラーム ページに移動し、標準モニタリング タブをクリックして、エンジンモニター セクションでキャッシュヒット率、 QPS、 TPS などのメトリクスを確認できます。
-
解決策
スレッドプール、高速クエリキャッシュ、自動 SQL スロットリングなどの機能を使用してパフォーマンスを向上させてください。
バッチ操作
-
原因と現象
大規模なデータのインポート、削除、またはクエリ操作は、SQL ステートメントの実行を遅らせる可能性があります。
ディスク領域の確認、SQL Explorer と監査の使用、またはスロークエリログの確認により、対応するステートメントを特定できます。たとえば、バイナリログ (binlog) ファイルのサイズを確認します。単一の binlog ファイルは通常 500 MB です。ファイルがこのサイズを超えた場合は、異常がないか確認してください。
また、コンソールの モニターとアラーム ページに移動し、標準モニタリング タブをクリックし、リソースモニター および エンジンモニター セクションでディスク容量、IOPS、トランザクションなどのメトリックを確認することもできます。
この例では、
mysql-binファイルのFile_sizeは 4,297,859,854 (約 4 GB) に達しており、これは正常な範囲を大幅に超えており、異常を示しています。 -
解決策
大規模な操作はオフピーク時に実行するか、より小さなバッチに分割して順次実行してください。
未クローズのトランザクション
-
原因と現象
CPU と IOPS の使用率が低いままで、アクティブセッションの数が継続的に増加しているときにタスクが突然遅くなった場合、未クローズのトランザクションが原因であることがよくあります。
-
解決策
トランザクションの競合を引き起こしているロックを検査し、対応する SQL ステートメントを終了してください。
スケジュールされたタスク
-
原因と現象
インスタンスの負荷が、時間の経過とともに規則的なパターンで変化する場合、スケジュールされたタスクが原因である可能性があります。
説明モニターとアラーム ページの 標準モニタリング タブで、関連するモニタリング情報を確認できます。
-
解決策
スケジュールされたタスクの実行時間を調整してください。オフピーク時に実行することを推奨します。
概要
次の方法で、ApsaraDB RDS インスタンスのスロー SQL ステートメントを特定できます。
これらの ApsaraDB RDS 機能は、スロー SQL ステートメントによって引き起こされる問題を迅速に特定し、自動的に解決するのに役立ちます。