21년 5월 24일 - DB 인덱스에 대하여

한 일

• mysql 인덱스에 대하여
  • mysql은 db 엔진으로 inno db를 사용한다.
  • mysql은 db 엔진의 인터페이스(storage engine interface)를 갖고 있고, 이를 구현한 구현체중 하나가 inno db이다.
  • db가 데이터를 저장하는 단위를 보통 레코드(row)라고 하고, 디스크에 페이지 단위로 모여서 저장된다(페이지 단위로 io가 일어난다).
  • row store는 레코드를 페이지에 저장을 하고, column store는 필드끼리 모여서 페이지에 저장된다.
  • 데이터베이스 페이지(디스크 저장 단위인 블록이라고 생각하면 편하다)의 최소 크기는 4KB이다.
  • 보통 인덱스는 B+ tree로 저장되고, B+ tree의 node하나는 page 하나를 통째로 사용한다.
  • 인덱스가 저장되는 페이지를 인덱스 페이지, 데이터가 저장되는 페이지를 데이터 페이지라고 한다.
  • B+ tree에서 데이터를 가리키는 포인터는 데이터페이지를 가리키는데, 이는 IO를 페이지단위로 처리하는게 빠르기 때문이다.
  • B+ tree와 B tree의 차이점은, B+ tree는 리프 노드에만 데이터페이지의 포인터를 갖고 있고, B tree는 모든 노드에서 데이터페이지의 포인터를 갖고 있기 때문에, B+ tree가 범위 검색에 훨씬 좋아서 DB에서는 B+ tree를 인덱스 자료구조로 사용함
    • https://python-wiki.appspot.com/?p=5846034605408256
  • fk는, 참조하는 pk로 존재하는 값이나 null만을 값으로 가질 수 있다.
  • fk를 새로 넣을 때마다, 해당하는 pk의 인덱스를 뒤져서 존재하는 값인지 확인한다.
  • fk는 자동으로 인덱스를 만드는데(B+ tree), 인덱스의 리프노드는 데이터페이지를 직접 가리킬 수도 있고, pk 인덱스페이지를 가리킬 수도 있다.
    • 여러가지의 이유로 보통, pk 인덱스페이지를 가리키는 간접 참조 방식을 사용한다. (써보니 좋았더라)
  • unique 제약조건을 설정해도, 인덱스를 만든다 (효율적으로 이미 존재하는 값인지 확인하기 위해 logN)
  • 인덱스를 설정하면 검색이 빨라지고 삽입 삭제가 느려지는 trade off가 있는데, 느려지는 이유는 인덱스의 재구조화 때문이다.(B+ tree 구조를 유지해야하기 때문이라고 이해하면 편함)
  • 커버링 인덱스
    • 찾으려는 값이 모두 인덱스로 설정되어 있으면, 인덱스 페이지까지만 접근하고 데이터 페이지에 접근할 필요가 없어진다.
    • 따라서 인덱스만으로 찾으려는 값을 찾을 수 있어서 커버링 인덱스라고 하며, IO 횟수가 줄기 때문에 훨씬 빠르다.
    • 테이블 A에 (B,C) 복합인덱스가 설정되어 있다고 해보자.
      • SELECT B,C FROM A WHERE B<100 AND C>50;
      • SELECT * FROM A WHERE B<100 AND C>50;
      • 이렇게 있을 때, 위에 있는게 훨씬 빠르다
      • 왜냐면 인덱스 페이지에 원하는 값이 모두 있기 때문에 데이터 페이지에 접근할 필요가 없어서 (커버링 인덱스)
    • B와 C에 각각 인덱스가 걸려있다면 커버링 인덱스 조건이 안된다.
      • B와 C중에 더 좋은 인덱스 하나만을 타고, 그 이후 걸러진 데이터에 대하여 나머지 조건을 확인하기 때문이다.
      • 결국 인덱스는 하나만 탈 수 있기 때문에, B,C 모두 얻으려면 데이터 페이지에 접근해야 한다.

느낌

• 오 하루 수업만으로 잘 모르던 내용을 많이 이해할 수 있었다. 호눅스 수업 짱짱

할 일

• 코드스쿼드 미션하기
• 프로그래머스 문제 풀기
• 면접 준비

• mysql
• database