클러스티드 인덱스와 논 클러스티드 인덱스

클러스티드 인덱스와 논 클러스티드 인덱스의 차이

정렬된 상태를 유지하는가, 추가적인 공간이 필요한가, 몇개의 인덱스를 걸수 있는가

한 테이블당 한개만 설정할 수 있고, 행과 인덱스가 같이 엮여 있는 형태이고 정렬된 순서 를 유지한상태로 저장이 됩니다.

실생활적인 예시를 들자면, 알파벳이 정렬된 상태로 유지된 영어 사전을 생각하면 편합니다.

index order	name
1	aMan
2	zMan

name 에 클러스티드 인덱스가 걸려있다고 가정해보겠습니다.
만약 위와 같은 데이터가 있고 cMan 이라는 데이터가 추가된다면, cMan은 알파벳 순서상 두개의 사이에 끼어 들어가서 정렬을 유지한 상태로 저장이 되어야합니다.
지금의 경우에는 데이터가 2개만 있지만, 1000만개 이렇게 대량의 데이터가 있다면, 중간에 데이터가 끼어 들어가는 과정은 DB에 굉장히 큰 부담을 주게 됩니다.
이런 이유때문에 일반적으로 auto-increment 가 되는 값을 클러스티드 인덱스로 잡게 되고, 대부분 PK로 사용합니다.
클러스티드 인덱스가 하나인 이유는, 여러 인덱스가 있는 경우에 어떤 것을 기준으로 정렬된상태 를 유지해야되는지 애매해지기 때문에 한 테이블에 한개만 제공하게 됩니다.

한테이블에 여러개를 설정할 수 있고, 인덱스는 데이터를 가르키는 포인터의 형태로 존재합니다.

실생활적인 예시를 들자면, 찾고자 하는 키워드와 실제 키워드가 적힌 페이지가 적혀있는 책 맨뒤의 인덱스 페이지를 생각하면 편합니다.

인덱스가 정렬된 상태를 유지할 필요가 없으므로 데이터가 중간에 추가될때 부담이 덜해집니다. 하지만 인덱스용 페이지를 위한 매핑과정이 있기 때문에 추가적인 공간이 필요하고 오버헤드가 중가합니다.
여러 열에 인덱스를 걸어둘 수 있습니다.

둘의 특징이 달라, 어느상황에서 무엇이 항상 좋다 라고 특정하기가 힘듭니다.

클러스티드 인덱스는 한개의 열에만 걸수 있습니다. 그리고 정렬된 상태를 유지하기 때문에 앞에서 이야기한것처럼 일반적으로 PK로 사용됩니다.
또한 다른 인덱스용 테이블을 관리할필요가 없고, 데이터에 바로 접근할 수 있어서 순차 탐색과 같은 부분에 있어서 좋습니다.
논 클러스티드 인덱스의 경우 데이터 행으로부터 독립적입니다. 여러 테이블에 걸수 있지만, 참조 테이블 때문에 추가적인 공간이 더 필요하고 접근할때 오버헤드가 있습니다.

https://dev.mysql.com/doc/refman/5.7/en/innodb-index-types.html
https://stackoverflow.com/questions/1251636/what-do-clustered-and-non-clustered-index-actually-mean
https://www.geeksforgeeks.org/difference-between-clustered-and-non-clustered-index/
https://www.sqlshack.com/what-is-the-difference-between-clustered-and-non-clustered-indexes-in-sql-server/
https://docs.microsoft.com/ko-kr/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-described?view=sql-server-ver15
https://youtu.be/NkZ6r6z2pBg