2025-09-26

오늘 배운 것

GROUP BY 실행 시 인덱스를 활용하는 방식은 어떤 경우에 가능하며, 루스 인덱스 스캔(loose index scan)이 특히 효과적인 상황은 언제인가요?

답변:

GROUP BY는 기본적으로 임시 테이블을 이용하지만, 조인의 드라이빙 테이블 칼럼만으로 그룹핑할 때 이미 해당 칼럼 인덱스가 있으면 인덱스 스캔을 통해 처리할 수 있습니다. 루스 인덱스 스캔은 단일 테이블의 GROUP BY에서만 적용되며, 유니크 값이 적을수록 성능이 좋아집니다. 다만 프리픽스 인덱스나 MIN/MAX 이외의 집합 함수가 포함되면 사용할 수 없고, SELECT 절과 GROUP BY 칼럼이 불일치하면 적용되지 않습니다.

DISTINCT와 GROUP BY는 내부 처리 방식이 유사한데, SELECT DISTINCT 구문을 사용할 때 주의해야 할 점은 무엇인가요?

답변:

DISTINCT는 특정 컬럼 하나만 유니크하게 조회하는 것이 아니라 SELECT 절 전체 레코드 조합을 유니크하게 만듭니다. 예를 들어 SELECT DISTINCT(first_name), last_name을 작성해도 first와 last 조합을 기준으로 유니크 레코드가 반환됩니다. 즉 특정 칼럼만 고유값을 뽑고 싶을 때는 별도 서브쿼리나 GROUP BY가 필요하며, 이 점을 착각하면 원하는 결과를 얻지 못할 수 있습니다.

내부 임시 테이블이 메모리에 생성되지 않고 디스크로 내려가는 경우는 언제 발생하며, 서비스 성능에 어떤 영향을 미치나요?

답변:

기본적으로 임시 테이블은 메모리에 생성되지만, 크기가 temptable_max_ram(기본 1GB)을 초과하면 디스크로 기록됩니다. 또한 GROUP BY/DISTINCT/UNION 등에서 칼럼 크기가 512바이트 이상일 때도 디스크 임시 테이블이 만들어집니다. 디스크 접근은 메모리보다 훨씬 느리므로, 대량 데이터 처리 시 응답 시간이 급격히 늘어날 수 있어 SQL 작성 및 칼럼 크기 설계 단계에서 고려가 필요합니다.

옵티마이저 스위치 중 MRR(Multi-Range Read)과 BKA(Batched Key Access)의 목적은 무엇이며, 기본적으로 비활성화된 이유는 무엇인가요?

답변:

MRR은 네스티드 루프 조인 시 드리븐 테이블 레코드를 모아서 정렬된 순서로 읽도록 하여 디스크 페이지 접근을 최소화합니다. BKA는 MRR을 응용한 방식으로, 드라이빙 테이블의 키를 모아서 한꺼번에 요청합니다. 그러나 이 과정에서 추가적인 정렬 비용이 발생할 수 있어, 데이터 분포에 따라 성능이 오히려 나빠질 수 있습니다. 그래서 MySQL에서는 기본값이 비활성화이며, 쿼리 패턴을 분석해 이득이 확실할 때만 활성화하는 것이 좋습니다.