Azure SQL Database がパフォーマンスの問題を抱えている場合、CPU 使用率を確認するだけでは不十分です。クエリは、リソースメトリクスが健全であっても、実行よりも待機に多くの時間を費やしている可能性があります。重要なのは、CPU がどれだけ使用されているかだけでなく、経過時間がどこに費やされているかということです。リソース使用率は最初のチェックポイントであるべきで、sys.dm_db_resource_stats に対するクエリで、CPU、データ IO、ログ IO、メモリ、またはワーカーの制限に近づいているかどうかを特定できます。リソースが飽和していない場合は、待機統計の分析が必要です。PAGELATCH_* (インメモリ競合) や LCK_M_* (ブロッキング) のような待機パターンは、さらに調査すべき領域を示します。PAGEIOLATCH_* 待機は物理 IO に関連し、PAGELATCH_* 待機はメモリ内のページでの同期に関係しており、単一のホットページでの高い同時実行性によって引き起こされる可能性があります。クエリ実行の頻度も、個々のクエリコストだけでなく、パフォーマンスに大きく影響します。Query Store はクエリ実行履歴を追跡するために不可欠であり、時間の経過に伴う期間、CPU 使用率、待機動作の比較を可能にします。クエリの経過時間が長いが CPU 使用率が低い場合は、ASYNC_NETWORK_IO のような待機を調査してください。これは、クライアントアプリケーションが結果を十分に速く消費していないことを示していることがよくあります。最初の行までの時間と最後の行までの時間を測定することで、データベースの応答時間と結果の消費時間を区別するのに役立ちます。セッションが別のトランザクションを待機する永続的なブロッキングも、CPU が低い場合でも、認識される遅延の原因となる可能性があります。データベースのスケーリングは、根本的なパフォーマンスのボトルネックに対処するのではなく、一般的なリソース可用性を向上させることで、根本原因を隠蔽する可能性があります。実践的なワークフローには、インシデントウィンドウの定義、リソースの確認、CPU と経過時間の比較、支配的な待機の特定、ブロッキングの確認、Query Store の使用、実行プランの検査、およびアプリケーションの調査が含まれます。最終的に、Azure SQL のパフォーマンスを効果的にトラブルシューティングするには、データベースがどれだけビジーに見えるかだけでなく、時間がどこに費やされているかを理解する必要があります。