2010-11-30 2 views
2

한 테이블을 다른 테이블보다 훨씬 느리게 만들 수있는 것은 무엇입니까? 아마 가장 쉬운 방법은 설명하기 :테이블을 "느리게"만드는 것은 무엇입니까?

쿼리 1 :

select top 1000 * 
from call c 
JOIN call_task ct ON c.call_no=ct.call_no 
LEFT JOIN memo_clt m ON m.doc_ref=ct.record AND m.doc_type='CLT' AND m.line_no=1 
LEFT JOIN memo_clt m2 ON m2.doc_ref=ct.record AND m2.doc_type='CLT' AND m2.line_no=2 

질의 2 :

select top 1000 * 
from call c 
LEFT JOIN ext_document_detail edd ON edd.doc_type='CLH' 
              AND edd.doc_ext_no=21 
              AND edd.doc_ref=c.record 
LEFT JOIN ext_document_detail edSource ON edSource.doc_type='CLH' 
               AND edSource.doc_ext_no=22 
               AND edSource.doc_ref=c.record 

테이블의 구조는 비슷합니다, 나는 매우 비슷한으로 ext_document_detail에 접근하고있어 가입 memo_clt 테이블에 비해. 두 번째 쿼리에는 40 초가 걸리지 만 다른 쿼리에는 0 초가 걸립니다.

둘 다 내가 조인에 사용하는 세 개의 키에 클러스터 된 인덱스가 있습니다. memo_clt 테이블은 레코드 컬럼에 클러스터되지 않은 인덱스를 가지고 있는데 ... 그것은 내가 발견 할 수있는 유일한 차이점이며 큰 차이를 만들 것이라고는 생각하지 않습니다.

왜 여기에 속도 차이가 있습니까?

편집 : 오른쪽 두 가지가 나 눈에 띄는하는 박쥐

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'ext_document_detail'. Scan count 1001, logical reads 1507004, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'call'. Scan count 1, logical reads 24, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

:

Table 'memo_clt'. Scan count 2000, logical reads 6454, physical reads 0, read-ahead reads 0, lob logical reads 2385, lob physical reads 0, lob read-ahead reads 0. 
Table 'call_task'. Scan count 1, logical reads 39, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'call'. Scan count 1, logical reads 25, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

질의 2 : 마틴 물었다 때문에, 여기 검색어 1 ON SET STATISTICS IO의 결과입니다. 첫째, "작업 테이블"과 같은 테이블이 없다는 것입니다. 두 번째는 논리적 인 읽기가 절대적으로 많습니다. 그 원인은 무엇입니까?

+0

둘 모두에 대한 실제 실행 계획은 무엇입니까? 두 가지 모두에 대해'SET STATISTICS IO ON'이 표시됩니까? –

+0

RE : 귀하의 커밋 ** "작업 테이블"과 같은 테이블이 없습니다. ** 실제 실행 계획에 해시 조인이 있다고 생각합니까? –

답변

2

속도 차이를 유발하는 것은 테이블 자체가 아닙니다. 질의되는 테이블에 대한 조인 및 지원 인덱스의 구조입니다.

속도의 차이에 대한 충분한 이유를 제공하려면 실행 계획을 확인해야합니다. 하나의 쿼리가 다른 쿼리보다 인덱스를 더 잘 사용한다고 생각합니다.

시작할 좋은 곳은 테이블 스캔이 있는지 확인하는 것입니다. 이러한 기능을 갖추고 최적화 할 수 있다면 성능이 향상 될 것입니다.

나는 this article을 잘 읽습니다. 확인하고 이해할 가치가 있습니다.

+1

나는 실행 계획을 더 일찍 봤어야했는데 암시 적으로 doc_ref를 int로 변환하는 술어가 있음을 알았다. 그래서 doc_ref가 varchar (50)로 저장된다는 것을 알게되었습니다. c.record를 varchar로 변환하도록 쿼리를 변경했으며 이제는 다른 쿼리와 동일한 속도로 실행됩니다. 감사! – CodeRedick