[업무에 바로 쓰는 SQL 튜닝] 4.2.4 열을 결합하여 사용하는 나쁜 SQL 문

목차

❌ 문제의 SQL 문
😎 실행 계획 살펴보기
⭕ 열을 결합하는 과정을 제거하고, 열을 분리해 보자
🚀 정리

 

❌ 문제의 SQL 문

요구사항 : 사원 테이블에서 성별의 값과 1칸의 공백, 성의 값을 모두 결합한 결과가 ‘M Radwan’인 데이터를 조회하는 쿼리를 작성해 주세요.

- CONCAT 함수는 여러 문자열을 연결하는 데 사용

SELECT *
    FROM 사원
    WHERE CONCAT(성별, ' ', 성) = 'M Radwan';

 

출력 :

총 102건이고 소요 시간은 약 0.13초가 나왔다.

 

😎 실행 계획 살펴보기

사원 테이블에만 접근하여 데이터를 가져오고 있다. 문제의 SQL문에서는 WHERE 조건절로 데이터에 접근하는 반면, 실행계획을 확인해 보니 type 항목이 ALL 테이블 풀 스캔을 하고 있다.

 

어떤 문제가 있는지, 테이블 인덱스 현황을 살펴보자.

SHOW INDEX FROM 사원;

기본키는 사원번호 열이고, I_입사일자 인덱스는 입사일자 열, I_성별_성 인덱스는 성별 열 + 성 열이다.

그럼 WHERE절에서 I_성별_성 인덱스를 활용해 데이터를 빠르게 조회할 수 있었을 것이다.

 

불필요하게 열을 결합하는 과정에서 문제가 생긴 것을 확인했다. 열을 분리해서 sql문을 다시 작성해 보자.

 

⭕ 열을 결합하는 과정을 제거하고, 열을 분리해 보자

SELECT *
    FROM 사원
    WHERE 성별 = 'M'
        AND 성 = 'Radwan';

소요시간이 약 0.13초에서 약 0.01초로 줄어들었다.

 

실행계획까지 확인해 보자.

I_성별_성 인덱스를 사용해서 테이블에 접근하고 있고, 튜닝 전에는 약 30만 건의 데이터에 접근했다면 튜닝 후에는 102건의 데이터에만 접근한다는 것을 알 수 있다. 그리고 type유형이 ref로 인덱스를 이용해 특정 조건(주로 =)에 맞는 데이터를 찾고 있다.

 

🚀 정리

테이블의 인덱스를 확인하는 습관 덕분에, 이미 설정된 인덱스가 효율적으로 사용되지 않고 있다는 사실을 알게 되었다. 멀티 칼럼 인덱스가 설정되어 있는 상태에서, 해당 열들을 결합한 쿼리문을 작성 시 인덱스가 활용되지 않을 수 있다는 것을 배웠다. 이런 경우에는 열을 나눠서 작성한 후 실행 계획을 확인하여 효율적인 탐색이 이루어지고 있는지 항상 점검해야겠다.

 

 

 

출처 : [도서] 업무에 바로 쓰는 SQL 튜닝