반응형
SMALL
동등 조건으로 인덱스를 사용하는 나쁜 SQL 문
현황 분석
| 튜닝 전 실행 계획 |
B 출입문으로 출입한 이력이 있는 정보를 모두 조회하는 쿼리
EXPLAIN
SELECT *
FROM 사원출입기록
WHERE 출입문 = 'B';
- 사원출입기록 테이블 : 660000 (약 66만)
- SQL문 결과 : 총 300000건의 결과 출력(30만), 0.35 sec 소요
- I_출입문 인덱스를 사용하여 데이터 접근 → 출입문 B에 대한 명확한 상수화 조건으로 인해 ref 항목이 const로 출력
튜닝 수행
SELECT 출입문, COUNT(1)
FROM 사원출입기록
GROUP BY 출입문;
- 출입문 B는 총 66만 건의 전체 데이터 중 30만 건
- 인덱스에 접근한 뒤 테이블에 랜덤 액세스하는 방식 → 전체 데이터의 50%에 달하는 데이터를 조회하려고 인덱스 활용이 효율적일지 고민
튜닝 결과
| 튜닝 후 실행 계획 |
내부 실행되는 인덱스를 무시할 수 있도록 IGNORE INDEX라는 힌트를 사용
EXPLAIN
SELECT *
FROM 사원출입기록 IGNORE INDEX(I_출입문)
WHERE 출입문 = 'B';
0.35 sec → 0.26ms (속도 개선)
type 항목 : ALL 로 수행 → 인덱스를 사용하지 않은채 약 66만 건의 전체 데이터를 가져와 조건절로 필요한 데이터 추출
랜덤 액세스가 발생하지 않음
한번에 다수의 페이지에 접근하는 테이블 풀 스캔 방식으로 수행 → 더 효율적인 방식
* 참고
반응형
LIST
'SQL 튜닝 > SQL 문 단순 수정' 카테고리의 다른 글
[SQL 튜닝] 범위 조건으로 인덱스를 사용하는 나쁜 SQL 문 (0) | 2023.07.18 |
---|---|
[SQL 튜닝] 엉뚱한 인덱스를 사용하는 나쁜 SQL 문 (0) | 2023.07.16 |
[SQL 튜닝] 인덱스 고려 없이 열을 사용하는 나쁜 SQL 문 (0) | 2023.07.15 |
[SQL 튜닝] 다수 쿼리를 UNION 연산자로만 합치는 나쁜 SQL 문 (0) | 2023.07.14 |
[SQL 튜닝] 습관적으로 중복을 제거하는 나쁜 SQL 문 (0) | 2023.07.13 |
댓글