전체 테이블 스캔

Full table scan

전체 테이블 스캔(시퀀셜 스캔이라고도 함)은 테이블의 각 행을 순차적(시리얼) 순서로 읽고 마주친 열이 [1]조건의 유효성을 검사하는 데이터베이스에서 이루어지는 스캔입니다.풀 테이블 스캔은 일반적으로 디스크에서 대량의 I/O 읽기가 필요하며 디스크에서 메모리로의 전송 비용이 많이 들기 때문에 가장 느린 테이블 스캔 방법입니다.

개요

데이터베이스에서 인덱스가 작성되지 않은 쿼리는 전체 테이블스캔이 됩니다.이 경우 데이터베이스는 테이블의 각 레코드를 처리하여 지정된 요건을 충족하는 모든 레코드를 찾습니다.쿼리가 테이블에서 몇 개의 행만 선택해도 전체 테이블의 모든 행이 검사됩니다.이로 인해 일반적으로 성능이 최적화되지 않지만 테이블이 매우 작거나 인덱스를 최신 상태로 유지하는 데 따른 오버헤드가 높을 경우 허용될 수 있습니다.

옵티마이저가 풀 테이블스캔을[3] 고려하는 경우

선택에서 가장 중요한 요소는 속도에 달려있다.즉, 가장 빠르고 다른 액세스 경로를 사용할 수 없는 경우 전체 테이블 검색을 사용해야 합니다.몇 가지 전체 테이블 검색 예는 다음과 같습니다.

  • 색인 없음

인덱스가 없으므로 옵티마이저는 전체 테이블 검색을 사용해야 합니다.

  • 행의 수가 적다

전체 테이블 검색 비용은 작은 테이블로 인해 인덱스 범위 검색보다 적습니다.

  • 쿼리를 처리할 때 SELECT COUNT(*) 열에 null이 있습니다.

쿼리가 일반 인덱스의 null 열 수를 카운트하고 있습니다.그러나 SELECT COUNT(*)는 null 열의 수를 셀 수 없습니다.

  • 쿼리가 선택되지 않았습니다.

반환 행의 수가 너무 많아 전체 표에서 거의 100%를 차지합니다.이러한 행은 선택되지 않습니다.

  • 테이블 통계가 업데이트되지 않음

테이블의 행 수가 이전보다 많아졌지만 테이블 통계가 아직 업데이트되지 않았습니다.옵티마이저는 인덱스를 사용하는 것이 더 빠르다고 올바르게 추정할 수 없습니다.

  • 그 테이블은 높은 평행도를 가지고 있다.

높은 수준의 병렬 테이블은 옵티마이저를 진정한 방법으로 왜곡합니다. 옵티마이저는 풀 테이블스캔을 사용하기 때문입니다.

  • 전체 테이블 검색 힌트

이 힌트를 통해 옵티마이저는 전체 테이블 스캔을 사용할 수 있습니다.

예

첫 번째 예에서는 빨간색인 과일 테이블의 모든 과일 이름을 반환하는 SQL 문을 보여 줍니다.과일 테이블에 색상 열에 대한 인덱스가 없는 경우 데이터베이스 엔진은 과일 내의 모든 행을 로드하고 검사하여 각 행의 색상을 '빨간색'과 비교해야 합니다.

과일에서 이름을 선택합니다. 여기서 색상 = '빨간색';

두 번째 예시는 후르츠 테이블 내의 모든 과일의 이름을 반환하는 SQL 문을 보여줍니다.이 문에는 WHERE 절이 없기 때문에 데이터베이스 엔진은 테이블 스캔을 사용하여 이름 열에 인덱스가 있더라도 이 쿼리의 데이터를 로드하고 반환합니다.이는 테이블에 직접 액세스하는 것이 인덱스의 추가 추상화 레이어를 통해 테이블에 액세스하는 것보다 빠르기 때문입니다.

과일에서 이름 선택

세 번째 예는 SQL 엔진에서 테이블스캔 대신 인덱스를 사용하는 경우가 대부분인 카운터 예시입니다.이 예에서는 이전 쿼리와 거의 동일한 쿼리를 사용하지만 ORDER BY 절을 추가하여 반환된 이름이 알파벳 순으로 정렬되도록 합니다.fruits 테이블이 name 열에 인덱스가 있다고 가정하면 인덱스의 추가 추상화 레이어를 통해 테이블에 액세스하면 요청된 순서로 행을 반환할 수 있기 때문에 데이터베이스 엔진은 인덱스를 사용하여 이름을 반환합니다.테이블 스캔을 사용하여 엔진이 행을 로드한 경우 반환된 행을 정렬하는 추가 작업을 수행해야 합니다.일부 극단적인 경우(예: 데이터베이스 엔진에 의해 유지되는 통계는 테이블에 매우 적은 수의 행이 포함되어 있음을 나타냄) 옵티마이저는 여전히 이러한 유형의 쿼리에 대해 테이블 스캔을 사용하도록 결정할 수 있습니다.

과일에서 이름을 선택해 주세요.

장점과 단점

장점:

  • 데이터베이스 시스템이 테이블 전체를 한 줄씩 스캔해야 하므로 비용은 예측 가능합니다.
  • 테이블이 데이터베이스 블록버퍼의 2% 미만일 경우 전체 검색 테이블이 더 빠릅니다.

단점:

  • 전체 테이블 검사는 인덱스가 없거나 SQL에서 사용되지 않을 때 발생합니다.또한 일반적으로 전체 스캔 테이블의 결과는 인덱스 테이블 스캔보다 느립니다.이 상황은 테이블이 클수록 데이터 반환 속도가 느려지는 것입니다.
  • 불필요한 풀테이블 스캔은 불필요한 I/O를 발생시켜 데이터베이스 전체에 프로세스 부담을 줍니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Avoiding Table Scans". Oracle. 2011.
  2. ^ "Which is Faster: Index Access or Table Scan?". Microsoft TechNet. 2002.
  3. ^ "Optimizer Access Paths". Oracle. 2013.