다음 기사 (만 Xiahun 말할 수있는, 개발은 정말 불가능하다) 그들이 맹점을 가지고있는 기록뿐만 아니라, 자신의 개발 과정을 공개하는 것입니다. 물론, 몇 가지 맹점도 작동 및 문의 프로세스는 다소 느리게 보이지만, 지금은 밖으로, 헌신 블로그 공원의 정신을 이월 당신과 함께 공유하고자합니다.
직접 타이틀로, 문 위의 내용 참조
실행 계획보기에서, 나처럼,이 같은 의심을해야합니까? 정확히뿐만 아니라, 검색 및 검사 내용과 자신의 쿼리 성능의 차이는 무엇인가. 여기 내 이해를 공유 할 수 있습니다.
SQL 서버는 스캔 찾아 테이블이나 인덱스에서 사용되는 반복자 데이터를 읽고, 때문에 종종 실행 계획에서 볼 수, 우리는 쿼리가 매우 중요한 의미가있다 최적화하기 때문에, 그들 사이의 차이점을 이해합니다.
테이블 스캔이 전체 테이블에서 수행되고, 인덱스 스캔이 페이지 수준을 통해 처리된다, 그러나, 하나 또는 술어에 여러 페이지를 찾기 위해 인덱스 찾아보기에, 그래서 그는 보통 인덱스는 발견 할 것이다 적은 IO 오버 헤드가 있습니다.
주사 여부에 관계없이 증상의 테이블의 전체 페이지 또는 행, 하나 하나가되기 때문이다. 따라서, 그 쿼리 비용 값이 주어지고, 결과 집합은 독립적 반환합니다. 인덱스 조회는 더 큰, 술어는, 일반적으로, 더 많은 결과 집합이 반환 여러 페이지에 비용을 수행한다.
그러나, 위의 설명에 의해, 우리가 믿을 수 없어, 모양은 좋지만, 스캔 (때문에 스캔 성능뿐만 아니라 병렬 처리 수준의 영향) 좋은 아니지만, 대부분의 경우, 데이터 특히 많은 양의, 결과 집합은 모든 스캔의 거리를 최적화 할 수있는 동안은, 성능을 스캔보다 더 나은 모습, 상대적으로 작은 돌아왔다.
여기, 우리는 조회 스캔 예에 의한 성능의 차이를 알게.
우리는 또한 사용 (1) 것은 SQL 서버 실행 계획 의 예 (색인이 이전에 삭제를).
우리는 다음 쿼리를 수행
인덱스 케이스 부재 1.
헤더에서 선택 ID, 금액, 할인, BuyDate
헤더에서 선택 ID, 금액, 할인, BuyDate 곳 BuyDate = '2008-09-15'
결과 : 결과는 단 하나 개의 데이터를 설정하지만, IO 오버 헤드를 줄이고, 여전히 전체 결과 집합이 동일 반환하지 않았더라도 테이블 스캔의 경우,.
인덱스 2. (반환 열을 충당하기 위해 비 클러스터형 인덱스는, 그렇지 않으면 RID 검색을 유발하거나 미래의 문서에 포함됩니다 키를 찾습니다.)
인덱스 만들기
헤더 (BuyDate)에 클러스터되지 않은 인덱스 index_headers_buyDate을 생성
(ID는, 금액, 할인)을 포함
이동
헤더에서 선택 ID, 금액, 할인, BuyDate
헤더에서 선택 ID, 금액, 할인, BuyDate 곳 BuyDate = '2008-09-15'
결과 : 상기 인덱스 스캔 인덱스 룩업 경우, 오버 헤드의 사용에 밀접 결과를 반환
개요
1. 때 술어 행을 만족하는 테이블 데이터가 거의 또는 상대적으로 긴 시간, 스캔 동작을 더 효율적으로 사용.
2. 테이블의 경우 술어 크게 가장 효과적인 방법은 아닙니다 데이터를 획득 할 페이지가 더 이상 I / O 작업을 수행 읽기 스캔을 만족하는 데이터 행의 적거나 많은 양의가 있습니다.
3. 찾아 항상 잘 보이지에 쿼리가 여러 스레드 (병렬) SQL 서버 수 있습니다 지정 있기 때문에, 스캔, 또한 나쁘지 않다 비해 스캔.
HTTPS : //www.cnblogs.com/mrzl/p/4076249.html 재현