최근 한 동료가 보안 권한을 조회하는 쿼리가 UserID (UNIQUEIDENTIFIER)에 대해 = 비교를 사용하여 실행하는 데 ~ 15 초가 걸리는 상황에 처했습니다. 말할 필요도없이, 사용자는 감명을 받았다.왜 LIKE가 =보다 빠릅니까?
불만에서 벗어나 동료는 = 비교를 사용하여 LIKE를 사용했고 쿼리가 1 초 미만으로 빠르게 진행되었습니다.
데이터베이스 또는 실행 계획에 대한 액세스 권한이없는 데이터 스키마에 대해 알지 못하면 잠재적으로 이러한 성능 변화가 발생할 수 있습니다.
(광범위하고 모호한 질문, 내가 아는)
캐시 된 실행 계획이 잘못되었을 수 있습니다. LIKE 문으로 변경하면 새 실행 계획이 생성됩니다. 사람이 문제의 테이블에서 sp_recompile을 실행 한 다음 = 쿼리를 다시 실행하면 동일한 속도 향상이 나타 났을 수 있습니다.
는이 테이블/데이터베이스 통계를 업데이트 시도? 시도해 볼 가치가 있습니다.
인덱스를 사용할 수있는 경우 LIKE은 SUBSTRING과 같은 기능보다 빠를 수 있습니다.
정확한 SQL을 줄 수 있습니까?
경우에 따라 함수를 사용하면 최적화 프로그램이 인덱스를 사용할 수 없게되는 경우가 있습니다.
실행 계획을 비교하십시오.
다른 가능성은 복잡한 쿼리이며 모든 행에 대해 = 연산자를 통해 유형 변환이 발생한다는 것입니다. LIKE는 의미 변환을 다소 변경하여 유형 변환이 실행 계획에 많은 영향을 줄 필요가 없도록합니다. 나는 실행 단계에서
CONVERT(varchar, variable) = othervariable
같은이있는 경우 귀하의 동료가 자리에 =와 실행 계획을 살펴 볼 것을 제안한다. 잘못된 상황에서는 단일 유형 변환으로 질의를 두 배 정도 느려질 수 있습니다.
이것은 매우 잘할 수 있습니다. PK가 UNIQUEIDTITIER이므로 일부 이상한 VARCHAR <-> GUID 캐스팅이 진행될 수 있습니다. –
두 쿼리를 차례대로 실행하면 첫 번째 쿼리에서 데이터를 디스크에서 읽어야하지만 두 번째 쿼리에서는 여전히 RDBMS 데이터 캐시에있을 가능성이 큽니다. .
이것이 일어난 경우, 반대 순서로 실행 한 경우 반대 결과를 보았을 것입니다 ... 정확한 값 (와일드 카드 없음)을 사용하면 쿼리 계획이 동일해야합니다 ..
이 제안 사항을 사용하여 동료에게 다시 돌아 왔습니까? –
나는 아직 실행 계획의 사본을 받았으며 이번 주말에 그들을 찾고있을 것이다. 제안을 전달하고 동료로부터받은 피드백을 게시합니다. –