LIKE는 색인을 사용하고 CHARINDEX는 사용하지 않습니까?

이 질문은 나의 오래된 질문 과 관련이 있습니다. 아래 쿼리는 실행하는 데 10-15 초가 걸렸습니다.

SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id]
FROM [company].dbo.[customer]
WHERE (Charindex('123456789',CAST([company].dbo.[customer].[Phone no] AS VARCHAR(MAX)))>0) 

일부 기사에서 나는 사용하는 것을보고 CAST및 CHARINDEX색인에서 혜택을받지 않습니다. 사용하는 것이 LIKE '%abc%'색인 생성의 이점을 얻지 못한다고 말하는 기사도 있습니다 LIKE 'abc%'.

http://bytes.com/topic/sql-server/answers/81467-using-charindex-vs-like-where /programming/803783/sql-server-index-any-improvement-for 같은 쿼리 http://www.sqlservercentral.com/Forums/Topic186262-8-1.aspx#bm186568

제 경우에는 다음과 같이 쿼리를 다시 작성할 수 있습니다.

SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id]
FROM [company].dbo.[customer]
WHERE [company].dbo.[customer].[Phone no]  LIKE '%123456789%'

이 쿼리는 이전 쿼리와 동일한 출력을 제공합니다. column에 대한 비 클러스터형 인덱스를 만들었습니다 Phone no. 이 쿼리를 실행하면 1 초 안에 실행됩니다 . 이것은 이전의 14 초 와 비교했을 때 큰 변화 입니다.

어떻게 LIKE '%123456789%'색인에서 혜택을?

나열된 기사가 성능을 향상시키지 않을 이유가 무엇입니까?

사용할 쿼리를 다시 쓰려고 CHARINDEX했지만 성능이 여전히 느립니다. 쿼리 CHARINDEX에서처럼 인덱싱의 이점 이 없는 이유는 무엇 LIKE입니까?

다음을 사용하여 쿼리 CHARINDEX:

SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id]
 FROM [Company].dbo.[customer]
 WHERE ( Charindex('9000413237',[Company].dbo.[customer].[Phone no])>0 ) 

실행 계획 :

다음을 사용하여 쿼리 LIKE:

SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id]
 FROM [Company].dbo.[customer]
 WHERE[Company].dbo.[customer].[Phone no] LIKE '%9000413237%'

실행 계획 :

'% 123456789 %'와 같은 인덱싱은 어떤 이점을 제공합니까?

아주 약간. 쿼리 프로세서는 전체 테이블 (클러스터형 인덱스) 대신 일치하지 않는 전체 비 클러스터형 인덱스를 검색 할 수 있습니다 . 비 클러스터형 인덱스는 일반적으로 작성된 테이블보다 작으므로 비 클러스터형 인덱스를 검색하는 것이 더 빠를 수 있습니다.

단점은 비 클러스터형 인덱스 정의에 포함되지 않은 쿼리에 필요한 모든 열을 기본 테이블에서 행별로 조회해야한다는 것입니다.

옵티마이 저는 테이블 추정 (클러스터형 인덱스)과 비 클러스터형 인덱스를 비용 추정치에 따라 조회하여 스캔합니다. 예상 비용은 옵티마이 저가 사용자 LIKE또는 CHARINDEX술어가 선택할 행 수에 따라 크게 다릅니다 .

나열된 기사가 성능을 향상시키지 않을 이유가 무엇입니까?

A에 대한 LIKE않는 조건 없는 와일드 카드로 시작, SQL Server는 수행 할 수있는 부분 스캔 전체를 스캔하는 대신 인덱스를. 예를 들어, LIKE 'A%제대로 만 인덱스 레코드를 테스트하여 평가 될 수 >= 'A'및 < 'B'(정확한 경계 값은 조합에 따라 달라집니다).

이러한 종류의 쿼리는 b-tree 인덱스의 탐색 기능을 사용할 수 있습니다. b-tree를 >= 'A'사용하여 첫 번째 레코드로 바로 이동 한 다음 < 'B'테스트에 실패한 레코드에 도달 할 때까지 인덱스 키 순서로 스캔 할 수 있습니다 . LIKE테스트를 적은 수의 행 에만 적용하면되므로 성능이 일반적으로 더 좋습니다.

반대로 LIKE '%A시작 또는 종료 위치를 모르기 때문에 부분 스캔으로 전환 할 수 없습니다. 모든 레코드는로 끝날 수 'A'있으므로 전체 인덱스를 스캔하고 모든 행을 개별적으로 테스트하는 것을 개선 할 수 없습니다.

사용할 쿼리를 다시 쓰려고 CHARINDEX했지만 성능이 여전히 느립니다. CHARINDEXLIKE 쿼리가 표시하는 것처럼 인덱싱의 이점 이 없는 이유는 무엇 입니까?

쿼리 최적화 프로그램은 두 경우 모두 테이블 (클러스터형 인덱스) 검색과 비 클러스터형 인덱스 (조회 포함) 검색간에 동일한 선택 을합니다.

비용 산정 에 따라 두 가지 중에서 선택 합니다. SQL Server가 두 가지 방법에 대해 다른 추정치를 생성 할 수 있습니다. 를 들어 LIKE쿼리의 형태로, 추정은 합리적으로 정확한 추정을 생성 할 수 있도록 특수한 캐릭터 통계를 사용할 수 있습니다. 이 CHARINDEX > 0양식은 추측을 기반으로 추정치를 생성합니다.

다른 추정값으로 옵티마이 CHARINDEX저가 클러스터 된 인덱스 스캔을 찾고 클러스터되지 않은 인덱스 스캔을 선택 합니다 LIKE. CHARINDEX쿼리가 힌트와 함께 비 클러스터형 인덱스를 사용 하도록 강요하면에 대한 것과 동일한 계획이 적용 LIKE되며 성능은 거의 같습니다.

SELECT
    [Customer name],
    [Sl_No],
    [Id]
FROM dbo.customer WITH (INDEX (f))
WHERE 
    CHARINDEX('9000413237', [Phone no]) >0;

런타임시 처리되는 행 수는 두 방법 모두 동일합니다 LIKE.이 경우 양식에서보다 정확한 추정이 생성되므로 쿼리 최적화 프로그램이 더 나은 계획을 선택합니다.

LIKE %thing%검색이 자주 필요한 경우 SQL Server의 Trigram Wildcard String Search에서 작성한 기술을 고려할 수 있습니다 .

SQL Server는 문자열 열의 하위 문자열에 대한 통계를 쿼리에서는 사용할 수 있지만에서는 사용할 수없는 시도 형식으로 유지 관리 LIKE합니다 CHARINDEX.

이에 대한 자세한 내용은 문자열 요약 통계 섹션을 참조하십시오.

몇 가지 중요한 경고는 와일드 카드를 이스케이프 처리하는 것은 ESCAPE키워드가 아닌 독점 대괄호 기술을 사용하여 수행해야하며 80 자보다 긴 문자열의 경우 첫 번째와 마지막 40 자만 사용한다는 것입니다.

WHERE ( Charindex('9000413237',[Company].dbo.[customer].[Phone no])>0 ) 

행의 30 %가 리턴 될 부등식 술어에 대해 표준 추측을 사용합니다.

LIKE(귀하의 경우) 쿼리는 아마 훨씬 적은 수의 행이 술어를 일치 추정하고있다.

선행 와일드 카드는 여전히 인덱스 탐색을 방지합니다. 전체 인덱스는 여전히 검색되지만 클러스터형 인덱스와 다른 다른 인덱스를 사용합니다. 더 좁은 인덱스는 쿼리에 사용 된 모든 열을 다루지 않으므로 두 번째 계획에서는 누락 된 열을 검색하기위한 키 조회가 필요합니다.

이 계획은 30 % 추정치로는 선택 될 가능성이 거의 없습니다. SQL Server는 전체 클러스터형 인덱스를 스캔하는 것이 더 저렴하다고 생각하고 많은 조회를 피합니다. 추가 예제 는 팁 포인트 에서이 기사를 참조하십시오 .