Lessons Learned #560: SQL은 느리다 — Query Store와 SSMS Copilot은 무엇을 밝혀낼 수 있는가?
최근 세션에서는 Query Store와 SSMS Copilot을 결합하여 SQL 성능 문제를 조사하는 방법을 시연했습니다. 데모에는 테이블을 증가시켜 성능 변화와 다른 쿼리 실행 계획을 유발한 PHP 프로그램이 포함되었습니다. 주요 관찰 사항은 동일한 Plan ID 하에서 쿼리 실행 시간이 극적으로 증가하여 계획 내 성능 저하를 나타냈다는 것입니다. 세션에서는 Copilot이 Ask 모드에서 Agent 모드로 발전하며 조사를 안내하는 방법과 이러한 프로세스를 재사용 가능한 스킬로 캡처하는 방법을 보여주었습니다. Query Store는 과거 성능 데이터를 제공했으며, Copilot은 이 데이터를 분석하고 다음 단계를 결정하는 데 도움을 주었습니다. 실질적인 시연에서는 PHP 프로그램을 사용하여 단계별로 테이블에 레코드를 추가하여 다양한 성능 문제를 시뮬레이션했습니다. 데이터 볼륨이 증가함에 따라 dbo.GiveNotes 쿼리의 실행 계획과 성능이 발전했습니다. 상세한 비교를 통해 새로운 계획이 도입되기 전에도 하나의 Plan ID에 대해 CPU, 지속 시간 및 논리적 읽기 수가 크게 증가했음을 밝혔습니다. 조사는 변경 사항의 타임라인을 구축하고 워크로드 기여자의 집계된 영향을 이해하는 데 중점을 두었습니다. 가중 평균은 다른 간격과 실행 횟수에 걸쳐 성능을 정확하게 평가하는 데 중요했습니다. 논리적 읽기 수의 증가는 데이터 처리 및 액세스 경로 문제를 가리켰습니다. 세션에서는 Copilot과 상호 작용하는 세 가지 방법, 즉 안내 질문을 위한 Ask 모드, 자율 진단을 위한 Agent 모드, 표준화된 조사를 위한 재사용 가능한 Agent 스킬을 탐구했습니다. SQL Performance Investigator 팩이 개발되어 에이전트에게 기여자 식별, 계획 기록 분석, 계획 내 성능 저하 확인, 선택성, 통계 및 인덱스 조사하도록 지시했습니다. 제안된 인덱스가 평가되었지만 실제 개선은 비교 가능한 워크로드에 대한 추가 검증이 필요했습니다. 핵심 교훈은 성능 변화를 이해하려면 계획 간의 차이점과 단일 계획의 기록 내 변형을 모두 검토해야 한다는 것입니다.
dbo.GiveNotes쿼리의 실행 계획과 성능이 발전했습니다. 상세한 비교를 통해 새로운 계획이 도입되기 전에도 하나의 Plan ID에 대해 CPU, 지속 시간 및 논리적 읽기 수가 크게 증가했음을 밝혔습니다. 조사는 변경 사항의 타임라인을 구축하고 워크로드 기여자의 집계된 영향을 이해하는 데 중점을 두었습니다. 가중 평균은 다른 간격과 실행 횟수에 걸쳐 성능을 정확하게 평가하는 데 중요했습니다. 논리적 읽기 수의 증가는 데이터 처리 및 액세스 경로 문제를 가리켰습니다. 세션에서는 Copilot과 상호 작용하는 세 가지 방법, 즉 안내 질문을 위한 Ask 모드, 자율 진단을 위한 Agent 모드, 표준화된 조사를 위한 재사용 가능한 Agent 스킬을 탐구했습니다. SQL Performance Investigator 팩이 개발되어 에이전트에게 기여자 식별, 계획 기록 분석, 계획 내 성능 저하 확인, 선택성, 통계 및 인덱스 조사하도록 지시했습니다. 제안된 인덱스가 평가되었지만 실제 개선은 비교 가능한 워크로드에 대한 추가 검증이 필요했습니다. 핵심 교훈은 성능 변화를 이해하려면 계획 간의 차이점과 단일 계획의 기록 내 변형을 모두 검토해야 한다는 것입니다.