인덱스의 중요성

• 읽기 속도를 빠르게 하기 위함
  • 조회할 때 인덱스를 이용해서 시작점을 빠르게 조회
• 쓰기
  • 쓰기를 할때 데이터 뿐만아니라 인덱스도 함께 추가해야 하기 때문에 추가적인 오버헤드 발생
  • 유니크 인덱스인 경우 일반 세컨더리 인덱스보다 쓰기가 느릴까??
    • 느릴 수있다고 생각하지만 크게 차이나지는 않을것으로 생각됌
    • 둘 다 btree를 타게되면 거의 비슷한 노드를 조회할것이고 해당 노드의 값이 같은지에 대해서만 비교하면 될듯함
    • 조회도 마찬가지로 성능이 크게 없을것으로 생각된다
    • 장점은 unique 인덱스인 경우에는 값이 1개밖에없어서 옵티마이저가 최적화 할수있음

Btree 구조

• 루트 노드 : 최상단
• 브랜치 노드 : 가운데
• 리프 노드 : 최하단 → pk인 경우 데이터와 붙어 있음 ,secondary 인덱스인 경우는 pk 포인터를 가리킴

• 특징
  • 항상 인덱스는 정렬되어있어야한다
  • 하지만 데이터는 무작위 순서대로 기록된다 (기본적으로 순차적으로 저장 , 데이터 삭제된 곳에 랜덤하게 저장)

인덱스 키검색

• 인덱스를 활용못할 때
  • 인덱스 변경 Upper(index) = ‘a’
  • wild card like( 전위 )
• gap lock에 사용할 인덱스가 없으면 전체 레코드를 잠글수도 있다

인덱스 키 값의 크기

• 블록( 페이지 ) 단위로 저장 ( os 의 블록 크기와 맞추는게 좋음 Block Split 방지)
• 인덱스의 키 크기가 커질수록 조회 속도가 저하될수 있다 + 버퍼풀의 캐시영역에 많이 저장할수가 없다 ( 메모리 효율 저하)
  • 키가 길면 인덱스 페이지를 메모리에 몇 개 못가지고 있기 때문에 range같은 조회시 메모리에 필요한 인덱스가 없는 경우 인덱스를 disk에서 가져와야 하기 때문에 i/o가 발생해서 느려진다

인덱스 btree depth

• 기본적으로 같은 depth에 최대한 많은 키를 담으려면 키의 크기가 작아야함 고로 위의 내용과 일맥상통