2016-08-16 2 views
0

실행하는 데 오랜 시간이 걸리지 만 동일한 테이블에서 count (*)를 실행하는 간단한 select 문이 있습니다. 동일한 WHERE 절이 1 초 이내에 돌아옵니다.매우 느리게 실행되는 단순 선택 쿼리이지만 동일한 테이블에서 매우 빠르게 실행되는 카운트 (*) 선택

이 쿼리는 아주 긴 시간 동안 실행

(1 시간 +가) :

SELECT col1 
     , col2 
     , col3 
    FROM Table 
    WHERE RowInsertDate >= @SomeStartDate 
    AND RowInsertDate < @SomeEndDate 

그러나이 쿼리 초 미만에 돌아 오면 :

SELECT count(*) 
    FROM Table 
    WHERE RowInsertDate >= @SomeStartDate 
    AND RowInsertDate < @SomeEndDate  

표는 3400 만 개 행이, 기본 키에 대해 ID 열과 지리적 영역 (북, 남, 동, 서) 열이 사용됩니다. 'RowInsertDate'열은 행이 테이블에 삽입 된 날짜입니다. 위 쿼리에 대한 예상 결과는 각각 'no rows'및 '0'입니다.

이 테이블의 클러스터 된 인덱스는 (ID, geoRegion) ASC입니다. 또한이 테이블에는 RowInsertDate ASC에 클러스터되지 않은 인덱스가 있습니다.

여기에서 어디로 가야할지 모르겠습니다. 누구도 전에 이것에 빠졌습니까?

+0

볼륨 물건 일 수 있습니다. 얼마나 많은 행이 반환됩니까? – Paparazzi

+0

이것은 실행 계획이 당신과 우리를 도울 것입니다. 또한 누구나 col1, col2를 인덱스에 연관시킬 수있는 방법이 없습니다. 우리는 인덱스가 어떤 컬럼인지 또는 색인에 포함되지 않았는지 모르기 때문에 그 값이 맞는지 또는 잘못되었는지 전혀 모릅니다. – Matt

+0

두 쿼리가 서로 다르며 다른 실행 계획을 초래합니다. – TheGameiswar

답변

1

select count(*)을 실행하면 SQL Server는 인덱스의 행을 계산할 수 있습니다. select col1,col2,col3을 실행하면 인덱스에있는 모든 행에 대해 SQL Server는 클러스터 된 인덱스 키 값 (인덱스에 저장된 ID, geoRegion)을 가져온 다음 해당 클러스터 된 인덱스 키 값을 사용하여 테이블에서 찾은 모든 행을 검색해야합니다.

클러스터 된 인덱스에 대한 모든 조회를 수행하는 것이 더 효과적 일 것이라고 생각하면 SQL Server는 클러스터 된 인덱스 검색 (또는 다른 방법)을 수행하기로 결정할 수도 있습니다. 쿼리 계획에서 어떤 일이 발생하는지 확인할 수 있습니다.

쿼리를 더 빨리 수행하려면 선택해야하는 열을 포함 된 열 또는 일반 열로 RowInsertDate에 추가하는 것이 좋습니다. 물론 열 수가 상대적으로 적을 경우 (또는 테이블에 대한 업데이트가 많지 않을 경우에만) 의미가 있습니다.

0

실행 계획을 확인할 수는 있지만 일반적인 BOOKMARK LOOKUP 문제라고 확신합니다. 그것은 자원을 소비하고 시간이 많이 소요됩니다. 한 가지 해결책은이를 다루기 위해 표지를 만드는 것입니다.

두 쿼리의 실행 시간은 완전히 다릅니다.

물론 열 (col1, col2, col3)이 어떤 데이터 형식인지 확인해야합니다.

이외에도 SET NOCOUNT ON을 설정할 수 있습니다. 희망이 도움이됩니다.

-2

쿼리가 매우 간단하므로.

SELECT col1 
    , col2 
    , col3 
FROM Table (nolock) 
WHERE RowInsertDate >= @SomeStartDate 
AND RowInsertDate < @SomeEndDate 
+2

그건 위험한 권고입니다 – Paparazzi

+0

@ 파파라치 : 선택 검색어 인 nolock은 위험합니다. –

+0

@AnjaniKumarAgrawal http://blogs.sqlsentry.com/aaronbertrand/bad-habits-nolock-everywhere/ – scsimon

0

ID가 고유 한 경우 (예를 들어, 정체성) 나는 당신이 PK 혼자 클러스터 있는지 확인 제안 : 나는 당신이 누락 것은 NOLOCK 생각합니다. 여분의 열은 조회를 위해 추가 데이터를 전달해야합니다.

나는 geoRegion이 1 바이트라고 희망합니다. varchar 그럼 당신이 필요 볼륨의 10 배를 들고 있다면. 이는 같은 양의 메모리에서 1/10의 인덱스입니다.

위의 문제가 해결되지 않는 경우 추가 응답의 지연에 대한 인덱스

CREATE NONCLUSTERED INDEX IX_Table_RowInsertDate 
ON Table (RowInsertDate) 
INCLUDE (col1, col2, col3); 
0

죄송에서 그 열을 포함한다.

서버 자체에 문제가있는 것처럼 보입니다. 우리의 로그에는 입출력 문제가 가득합니다. 우리는 DBA가 서버를 다시 시작하게하고 쿼리가 빠르게 실행됩니다.

정확한 문제의 성격이 무엇인지 확실하지 않지만 해결되었습니다. 이 똑같은 문제가 다시 발생하면 또 다른 질문을 올릴 것입니다.

관련 문제