Azure SQL Database에서 성능 문제가 발생했을 때 CPU 사용량만 확인하는 것은 불충분합니다. 쿼리는 건강한 리소스 메트릭에도 불구하고 실행되기보다는 대기하는 데 대부분의 시간을 보낼 수 있습니다. 중요한 질문은 단순히 CPU 사용량이 얼마나 되는지가 아니라, 경과 시간이 어디에 사용되고 있는가입니다. 리소스 사용량은 초기 점검 지점이 되어야 하며, sys.dm_db_resource_stats에 대한 쿼리를 통해 CPU, 데이터 IO, 로그 IO, 메모리 또는 워커 제한에 도달하고 있는지 확인할 수 있습니다. 리소스가 포화되지 않았다면, 대기 통계 분석이 필요합니다.인메모리 경합에 대한 PAGELATCH_* 또는 차단에 대한 LCK_M_과 같은 대기 패턴은 추가 조사가 필요한 영역을 나타냅니다. PAGEIOLATCH_ 대기는 물리적 I/O와 관련이 있으며, PAGELATCH_* 대기는 이미 메모리에 있는 페이지에 대한 동기화와 관련이 있으며 단일 핫 페이지에 대한 높은 동시성으로 인해 발생할 수 있습니다. 쿼리 실행 빈도 또한 개별 쿼리 비용뿐만 아니라 성능에 상당한 영향을 미칩니다. Query Store는 쿼리 실행 기록을 추적하는 데 중요하며, 시간에 따른 지속 시간, CPU 사용량 및 대기 동작을 비교할 수 있습니다.쿼리가 긴 경과 시간을 가지지만 CPU 사용량이 낮은 경우, 클라이언트 애플리케이션이 결과를 충분히 빠르게 소비하지 못하고 있음을 나타내는 경우가 많은 ASYNC_NETWORK_IO와 같은 대기를 조사하십시오. 첫 번째 행까지의 시간과 마지막 행까지의 시간을 측정하면 데이터베이스 응답 시간과 결과 소비 시간을 구별하는 데 도움이 될 수 있습니다. 세션이 다른 트랜잭션을 기다리는 지속적인 차단은 CPU 사용량이 낮더라도 인지된 느림을 유발할 수 있습니다. 데이터베이스를 확장하는 것은 근본적인 성능 병목 현상을 해결하기보다는 일반적인 리소스 가용성을 개선함으로써 근본 원인을 숨길 수 있습니다. 실용적인 워크플로우에는 인시던트 창 정의, 리소스 확인, CPU와 경과 시간 비교, 지배적인 대기 식별, 차단 확인, Query Store 사용, 실행 계획 검사 및 애플리케이션 조사 등이 포함됩니다. 궁극적으로 Azure SQL 성능을 효과적으로 문제 해결하려면 데이터베이스가 얼마나 바쁘게 보이는지만이 아니라 시간이 어디에 사용되고 있는지를 이해해야 합니다.