인덱스는 데이터를 찾는 과정이 필요한 모든 일 (Select, Update, delete, Insert 모두) 에 영향을 준다. 데이터를 빠르게 찾기 위해 필요하다.
인덱스 추가시 인덱스 관리 비용(처리하는 일, 인덱스 관리용 공간 필요)
하지만, 인덱스는 항상 타는게 아니다. 인덱스를 탈 때 통계를 참고하는데, 이 통계가 최적 수행 방법을 산출하려면, 통계가 최신에 가까워야 좋다.
아쉽게도 통계 갱신에는 비용이 존재하므로, 적절한 수위를 유지하는 것이 좋다.
인덱스가 걸려 있는 경우에는 정렬이 필요하다. 1Page가 꽉 찬 상태에서, 데이터가 중간 삽입 될 경우, 들어갈 데이터를 포함해 데이터를 반으로 쪼개서 두개의 페이지에 넣는다. 이 것을 페이지 분할이라 부른다.
페이지 분할이 자주 일어날꺼라 생각되면 인덱스 생성시 채우기 비율 설정으로, 미리 페이지 분할 해두는 것이 가능하다.
이렇게 할 경우, 페이지를 여러개로 나누는 만큼 페이지를 읽어오는 양이 늘어나는 부담이 생긴다. 검색에 사용된 인덱스가 유니크 인덱스일 경우에는, 데이터를 찾자마자 검색 과정을 중단하면 되기에 검색시에 더 빠르다.
인덱스 검사하는 법
explain select * from Table_Name where A=’a’ and B=’b’ order by C,D,E ;
해당 쿼리문이 인덱스를 타는지 안타는지 알기 위해서는 쿼리문 앞에 explain을 붙여주면 인덱스를 타는지 안타는지 알 수 있다.
type의 결과값이 ALL일 경우 인덱스를 타지 않는 상황이다. range,index등일 때 인덱스를 타고 있습니다. (system, const, eq_ref, range, index, ALL, fulltext)
key의 값이 해당 쿼리문이 타고 있는 인덱스입니다.
인덱스 관련 용어 정리
- Table Scan
- 인덱스를 사용하지 않고 테이블 전체를 읽는것.
- Index Seek
- 인덱스를 사용해서 데이터를 찾은 것.
- Random Access
- 여러 데이터를 찾을 때, 순차적으로 다음행을 읽지 못하고, 데이터 하나당 검색을 수행해야 하는 경우를 말함.
- Clustered Index (CI)
- 실제 데이터를 키에 따라 정렬 하는 것이다.
- 페이지 분할시 실제 데이터도 분할해야 하는 것이 단점이다.
- 범위 처리에 일반적으로 유용하다. (쿼리에 따라 다르지만)
- Non-Clustered Index (NI)
- 키 + 주소로 설정된 별도의 저장소를 가진다.
- 일반적으로 CI보다 크기가 작으므로, 한 페이지에 많이 들어간다. 데이터 검색시 페이지 간 이동이 CI보다 적다는 장점이 있다.
- 키에 따라 검색이 끝나도 실제 주소를 찾으러 가야하기 때문에, 범위 처리가 CI보다 느리다.
- Covered Query
- Index에 포함된 값만 필요로 해서 (a, b컬럼이 복합 인덱스로 걸려 있을 때 select a, b from table), 인덱스만 읽어서 결과를 보여줄 수 있는 쿼리를 말합니다.