인덱스 성능 최적화

인덱스는 비용이다

• 인덱스는 두 번 탐색하도록 강요
  • 인덱스 리스트, 그 다음 컬렉션 순으로 읽음
  • 관련 읽기 비용 더 든다
  • 그래서, 사용되지 않거나 중복되는 인덱스 제거 해야함
• 인덱스는 컬렉션이 수정되면 같이 수정 됨
  • 비용 발생
  • 책의 본문이 수정되었을때 찾아보기도 수정해야 되 듯
  • B-트리의 높이를 규형있게 조절 하는 비용 발생
  • 데이터 효율적으로 조회 위한 분산시키는 비용 발생
  • 인덱스에 포함된 컬럼 크기 클수록 인덱스 커지기 때문에 가능한 한 컬럼의 크기를 작게 유지하여 효율성 높여야 한다
    • 포인터!!!임

항상 테스트 하기

• 인덱스 최적화 기법은 도메인 특징 따라 다름
• EXPLAIN 통해 풀스캔 유무, 쿼리 처리시 행의 수 유무등 파악하고 최적화

복합 인덱스 설정 방법

• 복합 인덱스 설정시 인덱스 생성 순서도 중요

1. 어떤 값과 같음을 비교하는 == 이나 equal 이라는 쿼리 있다면 제일 먼저 인덱스로 설정
2. 정렬에 쓰는 필드 있다면 그 다음 인덱스로 설정
3. 다중 값 출력해야 하는 필드. 예를들어 BETWEEN, <, > 등 그 다음 인덱스로 설정
4. 카디널리티 높은 순서대로 설정(age, email 중 email을 먼저 설정)

MariaDB Document

https://mariadb.com/kb/en/getting-started-with-indexes/

• If you query contains something like LIKE '%word%', without a fulltext index you are using a full table scan every time, which is very slow.
• If your table has a large number of reads and writes, consider using delayed writes. This uses the db engine in a “batch” write mode, which cuts down on disk io, therefore increasing performance.
• If you are building a large table then for best performance add the index after the table is populated with data. This is to increase the insert performance and remove the index overhead during inserts.
  • 선삽입 후인덱싱