(MySQL) 인덱스

*MySQL에서는 인덱싱이나 검색 방식에 따라서 스토리지 엔진을 선택해야 할 수도 있기 때문에 여전히 인덱스에 대한 기본 지식은 중요하며, 쿼리 튜닝의 기본이다.



*데이터베이스의 성능 튜닝은 어떻게 디스크 I/O를 줄이느냐가 관건인 것들이 상당히 많다.


<랜덤 I/O와 순차 I/O>

->랜덤 I/O라는 표현은 디스크 드라이브의 플래터(원판)을 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽는 것을 의미하는데, 사실 순차 I/O 또한 이 작업은 같다.
순차 I/O는 3개의 페이지(16*3kb)를 디스크에 기록하기 위해 1번 시스템 콜을 요청하지만 랜덤 I/O는 3개의 페이지를 디스크에 기록하기 위해 3번 시스템 콜을 요청한다.
즉, 디스크헤드를 3번 움직이는 거시다. 즉, 순차 I/O는 랜덤 I/O보다 거의 3배정도 빠르다고 볼 수 있다.
즉, 디스크의 성능은 디스크 헤더의 위치 이동 없이 얼마나 많은 데이터를 한번에 기록하느냐에 의해 결정된다고 볼 수 있다. 그래서 여러 번 쓰기 또는 읽기를 요청하는 랜덤 I/O작업이 훨씬 작업의 부하가 커지는 것이다.
일반적으로 쿼리를 튜닝한다는 것은 랜덤 I/O 자체를 줄여 주는 것이적이다.
여기서 랜덤 I/O를 줄인다는 의미는 쿼리를 처리하는데 꼭 필요한 데이터만 읽도록 쿼리를 개선하는 것이다.


<인덱스란?>

칼럼(칼럼들)의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍(Key-value Pair)로 인덱스를 만들어 두는 것이다.
DBMS의 인덱스도 칼럼의 값을 주어진 순서로 미리 정렬해서 보관한다.
그래서 INSERT, UPDATE, DELETE문장 처리가 느리다.하지만 이미 정렬된 "찾아보기"용 표(인덱스)를 가지고 있어서 SELECT문장은 매우 빠르게 처리 할 수 있다.

1. B-Tree: 칼럼의 값을 변형시키지 않고 (물론 값의 앞부분만 잘라서 관리한다)인덱스 내에서 항상 정렬된 상태를 유지하고 있다.

• 인덱스와 실제 데이터가 저장된 데이터는 따로 관리된다. 인덱스의 리프노드는 항상 실제 데이터 레코드를 찾아가기 위한 주소 값을 가지고 있다.
• 많은 사람들이 데이터파일의 레코드는 Insert순서대로 저장되어있다고 생각하지만 그렇지 않다. 레코드가 삭제되어 빈 공간이 생기면 그 다음의 INSERT는 가능한 삭제된 공간을 재활용하도록 DBMS가 설계되어있다.(하지만 InnoDB테이블에서는 레코드는 클러스터되어 디스크에 저장되므로 기본적으로 Primary Key 순서대로 정렬되어저장된다.)