Partitioning

배경 ‘테이블에 1억 건 데이터가 있으면 조회가 느리다’는 말은 항상 참이 아님. 성능 저하는 데이터 양 자체보다 ‘어떤 쿼리를 어떤 인덱스로 어떻게 읽는가’의 문제일 때가 많음. 이 글에서는 대용량 테이블에서 조회 성능이 저하되는 주된 원인을 진단하고, 각 상황에 맞는 해결 전략을 정리함. 느린 쿼리의 대표적인 원인 대용량 테이블에서 쿼리가 느리다면 대부분 아래 원인 중 하나에 해당함. Full Table Scan: WHERE나 ORDER BY 절이 인덱스를 효과적으로 사용하지 못해 테이블 전체를 스캔 낮은 인덱스 선택도: 인덱스를 사용하더라도, status='ACTIVE'처럼 대부분의 행이 해당하는 조건이라 읽어야 할 데이터가 너무 많음 메모리 외부 정렬/그룹화: 정렬이나 그룹화할 데이터가 메모리 용량을 초과해 디스크 I/O가 발생하는 경우 (External Sort, Hash Aggregate) 비효율적인 조인: 조인 순서가 잘못되었거나 조인 키에 인덱스가 없어 비효율적으로 동작 OFFSET 기반 페이지네이션: OFFSET 1000000처럼 앞부분의 데이터를 모두 읽고 버리는 비효율적인 방식 기타 운영 이슈: 특정 행에 대한 동시 접근으로 인한 핫스팟(Hotspot), 잠금(Lock) 경합, 디스크 IOPS 부족, 캐시 미스 등 결론적으로 1억 건 테이블이라도 쿼리가 인덱스를 통해 소수의 행만 접근(Index Seek)하고 짧은 범위만 스캔(Range Scan)한다면 응답 속도는 충분히 빠를 수 있음. ...