쿼리 성능 조정

쿼리 / 저장된 프로 시저 / 함수 작성을 마치면 일부 성능 매개 변수를 빠르게 얻는 가장 유익한 방법은 무엇입니까? 쿼리를 실행하고 실제 실행 계획을 봅니까? 그렇다면 무엇을 찾으십니까? 분명히 테이블 / 인덱스 스캔은 비트 히트이지만 다른 것은 무엇입니까?

빠른 평가를 위해 실행 계획을 SSMS에서 계획 탐색기로 가져 오십시오 .

• 예상치 못한 일에 대해 가장 비싼 작업을 검토하십시오. 정렬, 작업 테이블, 부적절한 조인 연산자 (예 : 병합 또는 해시가 필요한 중첩 루프)
• 계획의 각 단계에서 행 수를 살펴보십시오. 예상 한 범위 내입니까?
• 예상 행과 실제 행을보십시오. 실제 수치가 추정치에 가까우면 계획이 좋은 것 같습니다. 큰 차이가있는 경우 이유를 찾으십시오 (예를 들어 누락되거나 오래된 통계).
• 매개 변수 스니핑 문제의 가능성을 평가하십시오. 카디널리티가 변할 수있는 영역을 찾고 다양한 입력 매개 변수에 대해 테스트하십시오.

Grant Fitchley의 SQL Server 실행 계획 은 무료로 제공되는 참조 자료가 많이 있습니다 . 또한 실행 계획 비용에 대한 Joe Chang의 블로그 게시물과 전자 책이 매우 유용하다는 것을 알았습니다 .

주로 내가하는 일은 쿼리를 실행하고 실제 데이터에 대해 어떻게 실행되는지 알아내는 것입니다. 문제가 있으면 실행 계획을 살펴 봅니다.

실행 계획에 관해서는, Brad McGehee는 그 주제에 관한 흥미로운 기사 를 가지고 있습니다.

그것에 그는 말한다 :

실행 계획에 다음 중 하나가 표시되면 경고 표시를 고려하여 잠재적 인 성능 문제가 있는지 조사해야합니다. 각각은 성능 관점에서 이상적이지 않습니다.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

이를 피하는 것이 항상 가능한 것은 아니지만 피할 수있을수록 쿼리 성능이 빨라집니다.

SET STATISTICS IO ON

일반적으로 "논리적 읽기 수"는 가능한 한 낮아야합니다. 쿼리를 완료하기 위해 터치 한 페이지가 적을수록 계획이 빠를수록 (일반적으로) 빠를수록 CPU, RAM 및 디스크 IO에 미치는 영향이 줄어 듭니다.

이것은 인덱스를 변경하거나 SQL의 리팩토링이 실제로 도움이 될 때 안내합니다. "밀리 초 예외 시간"을 보는 것은 동일한 SQL 및 쿼리 계획에 따라 다를 수 있습니다. 논리적 읽기는 주어진 쿼리 계획에 대해 일관성을 유지합니다.

또한 "물리적 읽기"는 매우 낮아야합니다 (그리고 후속 실행의 경우 0으로 유지됨). 이렇게하지 않으면 SQL Server 메모리 사용량 (페이지 수명 등)을보십시오.