페이지 매김 집계 쿼리가 전체 테이블을 가져 오는 것보다 시간이 덜 걸리는 이유

Question

데이터베이스에 테이블이 있고이 테이블에 세 열 (PropertyId, ConceptId 및 Sequence)의 인덱스가 있습니다. 이 특정 테이블에는 약 90,000 개의 행이 있으며이 세 가지 속성에 대해 색인이 생성됩니다. (

SELECT * 
FROM MSC_NPV 
ORDER BY PropertyId, ConceptId, Sequence 
OFFSET x * 10000 ROWS 
FETCH NEXT 10000 ROWS ONLY 

총 시간 : 내가 지금과 같은 쿼리를 페이지를 매기는 경우에, 그러나

SELECT * 
FROM MSC_NPV 
ORDER BY PropertyId, ConceptId, Sequence 

:

이제

나는이 쿼리를 실행할 때, 필요한 총 시간은 2보다 큰 분 x는 0에서 8로 간다) 요구되는 시간은 약 20 초에 불과하다.

단순한 쿼리를 넘어서는 추가 작업이 페이지 매김을 필요로하고이 쿼리를 전혀 병렬 처리하지 않았기 때문에 순차적 네트워크 호출에 필요한 추가 대기 시간을 추가하기 때문에 직관적이지 않습니다. 그리고 이러한 쿼리를 하나씩 실행하면 대기 시간에 큰 영향을 미치지 않기 때문에 캐싱 문제가 아니라는 것을 알고 있습니다.

내 질문은 이것입니다. 왜 다른 것보다 훨씬 빠른 이유는 무엇입니까?

Answer 1

여기에서 진행되는 작업을 장기간 검색 한 결과 성능 차이 (2 분 초과)의 원인은 Azure에서 데이터베이스를 호스팅했기 때문이라는 것을 발견했습니다. 하는 수, 쿼리를 주문하기 전에 모든 파티션에서 데이터를 가져옵니다 때문에

SELECT * 
FROM MSC_NPV 
ORDER BY PropertyId, ConceptId, Sequence 

더 느리게 실행됩니다 : 푸른 어떤 테이블을 분할하기 때문에 당신과 같은 쿼리를 실행하는 여러 파티션 (즉, 여러 기계)를 가로 질러에 개최 동일한 테이블의 여러 파티션에 대해 여러 개의 쿼리가 생성됩니다. 인덱스 된 속성을 통해 쿼리를 페이지 매김함으로써 특정 파티션을보고 거기에 저장된 테이블을 쿼리 했으므로 페이지가 지정되지 않은 쿼리보다 훨씬 뛰어난 성능을 보입니다.

는 이것을 증명하기 위해, 나는 다른 쿼리를 실행 :

SELECT * 
FROM MSC_NPV 
ORDER BY Narrative 
OFFSET x * 10000 ROWS 
FETCH NEXT 10000 ROWS ONLY 

이 쿼리 실행 anemically Narrative 파티션 키를 구축하는 푸른에서 사용하지 않는 때문에 기본 키하지 않고 있기 때문에 첫 번째 페이지가 매겨진 쿼리에 비해 . 따라서 Narrative을 주문하면 첫 번째 쿼리와 동일한 작업이 필요하고 그 위에 추가 작업이 필요하기 때문에 전체 테이블을 미리 가져와야했습니다.

Answer 2

매김이 넘는 추가 작업이 필요하기 때문에이 나에게 반 직관적 보인다 이후 간단한 쿼리

는

매김 몇 번 쿼리에 대해 매우 빠르고, 당신이 바로 인덱스가 있다면 ...

를 작동 예 : 아래 쿼리 사용

OFFSET x * 10000 ROWS 
FETCH NEXT 10000 ROWS ONLY 

읽을 수있는 최대 행은 20000 개입니다. 같은

RunTimeCountersPerThread 스레드 = "0"ActualRows = "60"ActualRowsRead = "60"

는 증명하지만 select * 쿼리 .. 당신은 모든 행을 읽고