관련이없는 열이 select 문의 쿼리 시간에 영향을 줍니까?


10

그냥 궁금 해서요

백만 개의 레코드 / 행 테이블이 있다고 가정하십시오.

select order_value from store.orders

실제 쿼리 시간에 해당 테이블에 1 개의 필드, 2 개의 필드 또는 100 개의 필드가 있는지 여부에 차이가 있습니까? "order_value"이외의 모든 필드를 의미합니다.

지금은 데이터를 데이터웨어 하우스로 푸시하고 있습니다. 때때로 나는 언젠가는 미래에 사용될 수있는 필드를 테이블에 덤프하지만, 지금 당장은 아무 것도 쿼리하지 않습니다. 이러한 '익명 한'필드가 직접 또는 간접적으로 포함되지 않은 선택문에 영향을 미칩니 까?


웹에는 이것에 대한 수많은 정보가 있습니다. 핵심은 기술이 변화함에 따라 최신 정보를 얻는 것입니다. 당신이 요구하는 것은 당신의 특정 설정에 너무 의존하여 아주 좋은 대답을 할 수는 없습니다. 기억해야 할 핵심 사항은 SSD로 전환 할 때 한때 성능에 매우 중요한 많은 것들이 더 이상 그렇지 않다는 것입니다.
Joe

답변:


10

이것은 실제로 인덱스 및 데이터 유형에 따라 다릅니다.

Stack Overflow 데이터베이스를 예로 사용하면 다음과 같이 Users 테이블이 나타납니다.

견과류

ID 열에 PK / CX가 있습니다. Id로 정렬 된 테이블 데이터 전체입니다.

이 인덱스를 유일한 인덱스로 사용하면 SQL은 해당 항목이 없으면 LOB 열을 메모리로 읽어야합니다.

DBCC DROPCLEANBUFFERS-- Don't run this anywhere near prod.

SET STATISTICS TIME, IO ON 

SELECT u.Id
INTO  #crap1
FROM dbo.Users AS u

통계 시간과 io 프로파일은 다음과 같습니다 :

Table 'Users'. Scan count 7, logical reads 80846, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 2406 ms,  elapsed time = 446 ms.

ID에 비 클러스터형 인덱스를 추가하면

CREATE INDEX ix_whatever ON dbo.Users (Id)

이제 쿼리를 충족하는 훨씬 작은 인덱스가 있습니다.

DBCC DROPCLEANBUFFERS-- Don't run this anywhere near prod.

SELECT u.Id
INTO  #crap2
FROM dbo.Users AS u

여기에 프로필 :

Table 'Users'. Scan count 7, logical reads 6587, physical reads 0, read-ahead reads 6549, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 2344 ms,  elapsed time = 384 ms.

우리는 훨씬 적은 읽기를 수행하고 약간의 CPU 시간을 절약 할 수 있습니다.

테이블 정의에 대한 추가 정보가 없으면 실제로 측정하려는 것을 더 잘 재현하려고 시도 할 수 없습니다.

그러나 당신은 그 고독한 열에 특정 색인이 없으면 다른 열 / 필드도 스캔 될 것이라고 말하고 있습니까? 이것이 행 스토어 테이블 디자인에 내재 된 단점일까요? 관련이없는 필드가 스캔되는 이유는 무엇입니까?

예, 이것은 rowstore 테이블에만 해당됩니다. 데이터는 행별로 데이터 페이지에 저장됩니다. 페이지의 다른 데이터가 쿼리와 관련이 없더라도 전체 행> 페이지> 인덱스를 메모리로 읽어야합니다. 나는 다른 열이 존재하는 페이지가 쿼리와 관련된 단일 값을 검색하기 위해 스캔되는 것처럼 "스캔"된다고 말하지 않을 것입니다.

ol '전화 번호부 예제 사용 : 전화 번호 만 읽는 경우에도 페이지를 넘기면 전화 번호와 함께 성, 이름, 주소 등이 바뀝니다.


@ jpmc26 요청한 열이 모두 인덱스의 일부인 경우 인덱스를 살펴보면 쿼리를 제공 할 수 있으므로 그보다 더 나빠질 수 있습니다. 열이 색인화 되지 않으면 1 차 레코드가로드되고 비 커스터드 테이블 / 열 유형의 2 차 레코드도 발생할 수 있습니다.
Christopher Schultz

12

테이블 구조와 사용 가능한 인덱스에 따라 다릅니다.

  • 사례 A : 공통 (rowstore) 테이블에 어떤 인덱스 (order_value).

    유일하게 가능한 실행 계획은 전체 테이블을 읽는 것입니다 (물론 2 대 200 열이므로 너비가 수천 바이트 인 경우에는 크게 다릅니다).

  • 사례 B : 공통 테이블, (order_value)해당 열을 포함하는 인덱스 또는 다른 인덱스가 있습니다.

    이제 더 나은 계획이 있습니다. 전체 색인 (그중 하나)을 스캔하십시오. 물론 전체 테이블보다 훨씬 더 좁습니다. 단지 몇 바이트입니다. 테이블에 2 또는 200 개의 열이 있으면 관련이 없습니다. 인덱스 만 스캔됩니다.

  • 사례 C : 컬럼 스토어 테이블입니다.

    이름에서 알 수 있듯이 이러한 테이블의 구조는 행 방향이 아니라 열 방향입니다. 인덱스가 필요 없으며 테이블 디자인 자체는 전체 열을 읽는 데 적합합니다.


내 지식은이 문제에 약간 녹색입니다. 행 저장소 테이블을 갖는 것이 가장 일반적인 방법입니다 (일반적인 SQL Server 데이터베이스). 하나의 열 / 필드 만 반환해야하는 경우 전체 테이블을 스캔하는 이유는 무엇입니까? 이것이 행 스토어 테이블 디자인에 고유 한 것입니까?
user45867

@ user45867 예, 데이터는 행에 저장됩니다 (외부에 저장된 매우 큰 열은 제외). SQL Server는 디스크에서 읽을 때 전체 블록을 읽으며 열이 하나 인 부분 만 읽을 수는 없습니다.
ypercubeᵀᴹ
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.