I/O와 버퍼 캐시

SQL 성능은 결국 읽는 양의 문제다

SQL 튜닝에서 가장 중요한 질문은 “얼마나 많은 데이터를 읽었는가”입니다. CPU 계산보다 디스크나 메모리에서 불필요하게 많은 블록을 읽는 것이 성능 저하의 주요 원인인 경우가 많습니다.

DBMS는 행을 하나씩 디스크에서 읽는 것이 아니라 보통 블록 단위로 데이터를 읽습니다. 필요한 행이 한 건이어도 그 행이 들어 있는 블록을 읽어야 합니다.

버퍼 캐시

버퍼 캐시는 디스크에서 읽은 데이터 블록을 메모리에 보관하는 공간입니다.

읽기 유형	의미	성능 감각
논리 읽기	메모리 버퍼 캐시에서 블록 확인	상대적으로 빠름
물리 읽기	디스크에서 블록을 읽음	상대적으로 느림

같은 SQL을 반복 실행했을 때 두 번째 실행이 빠를 수 있는 이유는 필요한 블록이 이미 버퍼 캐시에 올라와 있기 때문입니다.

전체 스캔과 인덱스 접근의 I/O 차이

전체 스캔은 테이블 블록을 넓게 읽습니다. 결과가 테이블 대부분이면 전체 스캔이 더 단순하고 빠를 수 있습니다.

인덱스 접근은 먼저 인덱스를 읽고, 필요한 행 위치를 찾아 테이블 블록에 접근합니다. 결과가 적으면 유리하지만, 결과가 많으면 테이블 블록을 반복해서 방문해 오히려 느려질 수 있습니다.

랜덤 I/O와 순차 I/O

구분	의미	예
랜덤 I/O	여기저기 흩어진 블록을 반복 접근	인덱스로 많은 행을 찾아 테이블 방문
순차 I/O	연속된 블록을 차례대로 읽음	대량 전체 스캔

인덱스가 항상 빠르지 않은 이유가 여기에 있습니다. 소량 조회에는 랜덤 I/O가 적어 유리하지만, 대량 조회에서 랜덤 I/O가 폭증하면 전체 스캔보다 느릴 수 있습니다.

튜닝 판단 기준

• 조건 결과가 전체 중 아주 적으면 인덱스 접근을 검토합니다.
• 결과가 많으면 전체 스캔이 더 나을 수 있습니다.
• 같은 블록을 반복해서 읽는 실행 계획인지 확인합니다.
• 정렬, 해시, 조인 과정에서 임시 공간을 과도하게 쓰는지 봅니다.
• 캐시 효과만 보고 SQL 자체가 빠르다고 착각하지 않습니다.

한 문장 요약