InJun2
commented
1 month ago - 인덱스 스캔이 풀 테이블 스캔보다 느린 이유
- 랜덤 I/O 오버헤드
- 인덱스 키를 기준으로 스캔을 진행하여 정렬되어 있는 리프노드의 인덱스 키를 순차적으로 처리할 수는 있으나 해당 인덱스 키(PK, Unique, Secondery 키 등)를 통해 데이터에 하나하나 랜덤 I/O를 발생하기 때문
- 순차 I/O 효율성
- 풀 테이블 스캔의 경우 모든 데이터를 순차적으로 읽기 때문에 순차 I/O 이며 연속된 디스크 블록을 읽어 매우 빠르기 때문
- 인덱스를 사용하면 인덱스를 정렬해야하는 유지보수로 인해 오버헤드가 발생해 추가적인 비용이 발생함
- 데이터 테이블 캐시
- 풀 테이블 스캔의 경우 연속된 블록으로 캐시 히트률이 높고 버퍼 풀에 캐싱되기 좋음
- 인덱스 스캔은 랜덤 I/O로 인해 다양한 위치의 데이터 페이지를 읽어 캐시 효율이 떨어질 수 있음
- 결론
- 인덱스 스캔의 효율성 : 인덱스 스캔은 특정 레코드나 소수의 레코드를 찾을 때 매우 효율적. 특히, 인덱스 유일 스캔은 특정 키를 빠르게 찾는 데 매우 유용
- 풀 테이블 스캔의 효율성 : 풀 테이블 스캔은 많은 레코드를 읽어야 할 때 효율적. 이는 시퀀셜 I/O와 높은 캐시 효율성 덕분
- 적절한 사용 기준 : 검색해야 할 레코드 수(옵티마이저가 판단한 예상 건 수)가 전체 테이블의 20~25% 이하일 때 인덱스를 사용하는 것이 효율적. 이를 초과하면 풀 테이블 스캔이 더 나은 성능을 보일 수 있음
- 인덱스 스캔 최적화하는 방법
-
인덱스 스캔은 리프노드의 인덱스 키를 순차적으로 조회하지만 해당 인덱스 키에 맞는 레코드를 임의로 찾아야하므로 결국 하나하나 랜덤 I/O가 발생하게됨
-
인덱스 캐싱
자주 사용되는 인덱스를 메모리에 캐시하여 빠른 액세스를 지원하여 랜덤 I/O를 줄이고 성능을 향상함
-
I/O 연산 최적화
DBMS에서 디스크 액세스를 최적화하는 다양한 기술을 사용함 인접한 블록을 함께 읽는 프리페칭(pre-fetching) 기술이나 쓰기 연산을 배치 처리하는 방법들이 존재
-
인덱스 정렬 및 구조 최적화
인덱스의 물리적인 구조를 최적화하여 랜덤 I/O를 줄이는 방법이 있음 예를들면 클러스터드 인덱스(Clustered Index)는 데이터 행과 인덱스 키를 동시에 정렬하여 랜덤 I/O를 최소화할 수 있음
-
압축 기술
압축을 통해 인덱스의 크기를 줄이고 압축된 작은 인덱스는 메모리에 더 많은 데이터를 캐시할 수 있음
-
인덱스 레인지 스캔, 인덱스 풀 스캔, 루스 인덱스 스캔, 인덱스 스킵 스캔은 모두 리프노드의 인덱스 페이지를 스캔하는 방법이고 캐싱된게 없거나 최적화 방안이 사용된 것이 없다면 데이터를 찾는데에는 모두 랜덤 I/O를 발생
진행내용
5월 30일 RealMySQL 8챕터 인덱스 스터디 진행
하고싶은 이야기 및 문제를 답변으로 작성해주세요