1. 참조: https://www.youtube.com/watch?v=nvnl9YgnON8&t=701s
2. 인덱스를 사용하는 이유
   1. 조회 성능 개선 → 디스크I/O를 줄이는 것 랜덤IO와 순차IO
   2. 인덱스를 사용하면 CUD 기능은 저하됨(CUD가 진행될 때 마다 인덱스 정렬, 특정 위치로 이동등을 수행)
   3. READ의 경우 인덱스를 활용하면 더 빠르게 조회가 가능함
   4. 보통 서비스에서 R : CUD의 비율이 8:2 or 9:1로 진행됨
   5. 위 이유로 CUD의 성능의 저하를 감수하더라도 READ의 성능을 올리기 위해 인덱스를 활용
   6. 기본적으로 select → where → group by → order by → limit 순서
   7. group by의 경우 인덱스 컬럼 순서대로 사용되어야 적용 가능(where 절에 사용된 인덱스 컬럼은 생략 가능)
   8. order by의 경우 인덱스를 활용할 수 있으면 인덱스가 생성된 그대로 읽으면 됨(역방향일 경우 인덱스를 역으로 조회해서 얻을 수 있음)
   9. group by, order by 인덱스 사용조건은 비슷하지만, order by에서는 인덱스 정렬의 정순 또는 역순의 경우에만 사용이 가능함
3. 실행 계획의 종류
   1. all: 테이블 풀 스캔
   2. index: 인덱스 풀 스캔
   3. range: 인덱스 레인지 스캔
4. 인덱스의 선택
   1. 기본적으로 PK로 설정한 컬럼에 대해서는 클러스터 인덱스가 생성
   2. 서비스에서 조회가 많이 되는 컬럼을 선정
   3. 컬럼중에서 카디널리티(유일성)가 높은 컬럼을 선정
5. 다중 컬럼 인덱스
   1. 두 개 이상의 컬럼을 사용해서 인덱스를 생성
   2. 하나의 컬럼을 인덱스로 사용하는 경우보다 더 적은 데이터 분포를 가지므로 조회 범위가 줄어듦
   3. 2개의 컬럼으로 다중 컬럼 인덱스 생성한 경우
      1. 지정한 순서대로 인덱스가 생성됨
      2. 첫번째 컬럼으로 먼저 정렬이 되고 첫번째 컬럼에 대해 두번째 컬럼이 정렬
6. 커버링 인덱스
   1. 인덱스를 통해 조회할 때 가장 부하를 많이 가지는 부분이 리프 노드의 주소를 이용해서 조회를 할 때(디스크를 통한 I/O가 발생)
   2. n개의 레코드를 조회할 때 최악으로는 n번의 I/O가 발생
   3. 풀 테이블 스캔은 25%넘을 경우 인덱스 활용 못함
   4. 커버링 인덱스는 인덱스로 만든 컬럼만 조회하는 경우 디스크 조회가 불필요하게 되는데, 이를 커버링 인덱스라고함
   5. 하지만, PK로 설정한 컬럼은 인덱스로 만들지 않아도 커버링 인덱스로 처리가 됨
   6. 이유는 인덱스에서 리프 노드는 PK를 주소로 가지기 때문에 인덱스로 만들지 않아도 커버링 인덱스 처리가 가능함
7. 범위 조건, 체크 조건
   1. 인덱스 컨디션 푸시다운
   2. extra 컬럼도 확인 → explain
8. 키워드
   1. 인덱스 스킵 스캔
   2. 루스 인덱스 스캔
   3. 유니크 인덱스
   4. 전문 검색 인덱스
   5. 옵티마이저