답변:
쿼리 튜닝 101
힌트와 팁을 줄 수는 있지만 쿼리 튜닝에 대한 마법의 총알은 없습니다. 가장 먼저 할 일은 실제로 뒤에서 일어나는 일을 이해하는 것입니다. 세 번째 전문가 안내서와 같은 좋은 내부 도서를 얻으십시오.
성능이 좋지 않은 쿼리는 두 가지 기본 풍미가 있습니다. 너무 오래 걸리는 트랜잭션 쿼리와 너무 오래 걸리는 일괄 작업 (또는 보고서). 쿼리에 문제가있는 좋은 표시 중 하나는 쿼리 계획에서 99 %의 시간이 걸리는 단일 항목입니다.
트랜잭션 쿼리
대부분의 경우 성능이 좋지 않은 트랜잭션 쿼리는 다음 중 하나입니다.
누락 된 색인. 쿼리 계획에서이를 확인할 수 있습니다. 조인에서 큰 테이블의 테이블 스캔은 매우 선택적이어야합니다 (즉, 몇 개의 행을 반환 함).
쿼리가 인덱스를 사용할 수 없습니다. where 절에 OR 조건이 있고 계산 된 값이나 sarg 불가능한 쿼리의 다른 항목에 조인하는 경우 쿼리를 다시 작성해야 할 수 있습니다. 간단히 말해 sargs 는 인덱스를 사용하여 행을 제거 할 수있는 쿼리 조건 자입니다. 논리 AND, 평등 및 불평등 (>,> =, <, <= 및! =)은 모두 sarg 가능합니다. OR은 전통적으로 처칠 수 없습니다. 그러나, OR에서 NOT (foo and not bar) 유형 구문으로 센스를 반전하여 OR을 sargable 술어로 변환 할 수 있습니다.
비효율적 인 술어. 예를 들어 where in중첩 된 하위 쿼리를 참조하는 경우 하위 쿼리를 where exists조인 으로 다시 작성할 수 있는지 확인하십시오 . 이로 인해보다 효율적인 쿼리 계획이 생길 수 있으며 여기에 시도 할 수있는 다른 표준 재 작성이 있습니다. 다시 말하지만, 주제에 관한 전문가 가이드 책과 다른 것들이 좋은 출발점입니다.
배치 쿼리
배치 쿼리는 더 복잡하고 다른 튜닝 문제가 있습니다. 몇 가지 팁은 다음과 같습니다.
인덱싱. 이는 트랜잭션 쿼리와 같은 이유로 큰 차이를 만들 수 있습니다. 누락 된 인덱스의 좋은 신호는 종종 기계를 손상시키지 않는 긴 연삭 작업 (쿼리 계획의 99 %)입니다.
임시 테이블. 쿼리를 임시 테이블을 채우는 여러 쿼리로 나누는 것이 좋습니다. 더 큰 쿼리는 옵티마이 저가 더 큰 문제를 해결할 수있는 공간을 제공하지만 이전에는 문제가되지 않았습니다. select into이 작업이 최소한으로 기록되므로 (로그 작업이 훨씬 적음) 임시 테이블을 만들어 I / O로드를 줄입니다. 임시 테이블은 쿼리를 통해 추적하기가 더 어려워 질 수 있으므로 과도하게 사용하지 마십시오. 저장 프로 시저 내의 작은 테이블의 경우 테이블 변수가 도움이되는지 테스트하십시오. 이들은 메모리 내 데이터 구조이므로 성능이 향상 될 수 있습니다.
tempdb의 임시 테이블은 옵티마이 저가 중간 조인 결과를 저장하는 데 사용하는 것과 동일한 데이터 구조이므로이 작업을 수행하면 성능이 저하되지 않습니다. 임시 테이블에서 인덱스 (클러스터 된 인덱스 및 커버링 인덱스 포함)를 만들 수도 있습니다. 이렇게하면 정적 테이블에서 쿼리를 향상시키는 것과 같은 이유로 인덱스를 읽는 쿼리의 성능이 향상 될 수 있습니다.
클러스터 및 커버링 인덱스. 이들은 일부 그룹화 열을 기반으로 디스크에서 참조의 지역성을 강요하므로 쿼리 성능을 향상시킬 수 있습니다. 클러스터 된 인덱스는 배치 작업의 성능에 큰 차이를 만들 수 있습니다.
비효율적 인 술어. 이로 인해 트랜잭션 쿼리와 거의 같은 방식으로 sargs 및 기타 하위 최적화 문제가 발생할 수 있습니다.
테이블 스캔은 당신의 친구입니다. 대중적인 믿음과는 반대로, 테이블 스캔은 본질적으로 악하지 않습니다. 일반적으로 트랜잭션 쿼리에서 문제가 있음을 나타내지 만 대규모 일괄 작업을 수행하는 가장 효율적인 방법입니다. 테이블에서 몇 퍼센트 이상의 행으로 작업을 수행하는 경우 테이블 스캔은 테이블을 처리하는 가장 효율적인 방법입니다.
중첩 루프 조인 옵티마이 저가 조인의 양쪽에서 수행하는 작업을 살펴보십시오. 예를 들어 중첩 루프 조인의 양쪽에있는 두 개의 큰 테이블을 스캔하는 테이블을 스캔하는 경우 비효율적 일 수 있습니다. 클러스터 된 인덱스를 사용하거나 order by한 쪽이 이 작업을 수행 할 수있을 정도로 작습니다.
잠금
잠금으로 인해 성능 문제가 발생할 수도 있습니다. 시스템이로드 상태에서 제대로 작동하지 않는 경우 잠금과 관련된 프로파일 러 및 perfmon 카운터를보고 심각한 경합이 있는지 확인하십시오. sp_who2결과 집합에 'BlkBy'열이있어 쿼리가 차단되었는지 여부와 차단 대상을 표시합니다. 또한 '교착 상태 그래프'이벤트 (쿼리 교착 상태가있는 경우) 및 잠금 관련 이벤트가있는 프로파일은 잠금 문제를 해결하는 데 유용 할 수 있습니다.
SQL Server 실행 계획 작업 및 이해 방법에 관한 RedGate의 무료 무료 전자 책
http://www.red-gate.com/specials/Grant.htm?utm_content=Grant080623
뻔뻔한 플러그, 나는 블로그에서 SQL Server Performance 아래의 성능 조정 자료를 참조합니다 .
이 자료의 일부를 소화 할 기회가 있으면 여기에 게시하거나 특정 질문이있는 경우 저에게 직접 연락하십시오.
먼저 인덱싱. 많은 사람들은 외래 키가 자동으로 인덱스를 얻지 못한다는 것을 인식하지 못합니다. 조인에 사용되므로 거의 항상 색인이 있어야합니다.
모든 커서를 면밀히 검사하여 대신 세트 기반 코드로 대체 할 수 있는지 확인하십시오. 이 작업을 수행하여 몇 시간에서 몇 초 동안 실행 된 코드를 변경했습니다.
하위 쿼리를 피하십시오. 코드에 포함 된 경우 파생 테이블에 대한 조인 또는 조인으로 대체하십시오.
where 절을 검색 할 수 있는지 확인하십시오.
실행 계획을 읽는 법을 배우십시오.
사무실에 성능 조정에 대한 몇 가지 좋은 책이 있는지 확인하십시오.
어떤 경우에는 테이블 변수가 임시 테이블보다 우수하고 다른 경우에는 임시 테이블이 더 잘 수행됩니다.이를 사용해야하는 경우 두 가지를 모두 시도하고 특정 상황에서 어떤 것이 더 효과적인지 확인하십시오.