728x90
인덱스를 다룰대 주의해야 할점
0. Cardinality가 높은 컬럼에 사용
- 중복이 적으면 카디널리티가 높다.
- ex) 마트 품목(소고기/돼지고기/닭고기/콜라/사이다/햇반/어묵 등등....)
- 중복이 많으면 카디널리티가 낮다.
- ex) 성별(남/여)1. 인덱스 필드 가공
잘못된 예제
// age는 int 타입
SELECT *
FROM Member
WHERE age * 10 = 1 // 1. BTree 형태 이므로 가공 하면 Index 비교가 되지 않는다
WHERE age = '1' // 2. age는 int 타입이므로 Index 비교가 되지 않는다
2. 복합 인덱스
예제 1. 단일
과일 | PK |
---|---|
Apple | 1 |
Banana | 4 |
Banana | 5 |
Butter | 3 |
예제 2. 복합
과일 | 원산지 | PK |
---|---|---|
Apple | USA | 1 |
Banana | CHINA | 4 |
Banana | KOREA | 5 |
Butter | KOREA | 3 |
> 예제 2번과 같이 복합 Index일 경우 "첫번째"로 "과일"이 정렬이 되고 이후 "원산지"가 정렬이 된다.
> 따라서 WHERE 에 "원산지"만 비교 하면 Index를 비교 하지 않고
> "과일"만 비교 하면 "Index를 비교" 한다.
중요
따라서 복합 인덱스 일경우 선두 컬럼이 어떤거냐가 매우 중요하다!!
3. 하나의 쿼리에는 하나의 인덱스만
- 하나의 쿼리에는 하나의 인덱스만 탄다.
*여러 인덱스 테이블을 동시에 탐색하지 않는다.
- Index merge hint를 사용하면 가능
- WHERE, ORDER BY, GROUP BY 혼합해서 사용할때는 Index를 잘 고려해야한다.
- WHERE절에는 Index를 탔지만 ORDER BY, GROUP BY에는 Index를 타지 않으면 읽어온 데이터를 모두 다시 설정해야 한다.
- 의도대로 인덱스가 동작하지 않을 수 있음. EXPLAIN으로 확인
- INDEX도 비용이다. 쓰기를 희생하고 조회를 얻는 것
- 꼭 인덱스로만 해결할 수 있는 문제인가?
728x90