카디널리티 cardinality
- 중복도
- cardinality: 유니크한 값의 대략적인 숫자
카디널리티가 높다: 다양성이 크다
이름: 박 김 이 최 등등 제일 다양하다
성별: 남 여 두개밖에 없으므로 카디널리티가 가장 낮다
나이: 20대 30대 40대 등등이 있다
// 카디널리티 확인 1
SELECT COUNT(DISTINCT brand)
FROM products;
// 카디널리티 확인 2
// 이미 인덱스가 있는 경우
SHOW INDEX FROM products;- 카디널리티 비율: distict 값 / 전체 row
- 전체 row SHOW TABLE STATUS LIKE 'products';
낮을수록 인덱스 효과가 낮다.
-> 인덱스 설정은 카디널리티가 너무 높아도 비효율적, 너무 낮아도 비효율적
옵티마이저
- sql 계획을 세우는 dbms 내부 엔진
- 가장 효율적인 인덱스, 조인 순서, 쿼리 최적화 방법을 선택한다
- 항상 최적의 선택을 하는 것은 아니므로, use index/force index/ignore index 같은 것을 통해 개발자가 제어 가능
인덱스 단점
- 불필요한 저장공간이 생기게 됨
- 쓰기 시 성능 저하(기존 인덱스 삭제 후 재삽입)
- EXPLAIN ANALYZE 로 계획/비용을 확인할 수 있음
- 카디널리티 낮은 컬럼(성별, 상태)에 인덱스를 만들면 풀 스캔과 큰 차이가 없음
- show index 해서 대락적인 유니크 값 수 확인 가능
- 왼쪽부터 일치해야 인덱스를 활용함
- 함수/연산은 인덱스를 안 탈 수 있다
함수/연산
- 인덱스 무력화
- where date() = '', where price * 1.1 > 1000, where name like '%lee' 등
- WHERE created_at >= '2025-09-17 00:00:00' AND created_at < '2025-09-18', WHERE name LIKE 'lee%' 등으로 수정하기
커버링 인덱스
- 쿼리에 필요한 모든 컬럼이 인덱스에 포함되어 있어 테이블 데이터를 조회하지 않고 인덱스만으로 결과를 반환할 수 있는 인덱스
참고
- 점조건, 정렬, 범위 순서로 인덱스를 만들어야 인덱스를 잘 탄다
- 중복도가 너무 낮으면 인덱스가 소용이 없다
과제
- 수업에서 했던 모든 쿼리들이 한 개의 시스템에서 일어나야 한다면 인덱스를 어떻게 합칠 수 있을까?
도전