none
클러스터 인덱스 생성 시 DESC로 생성의 질문 RRS feed

  • 질문

  • a 컬럼 identity (1, 1)로 설정되어 있습니다. 따라서, 계속 값이 증가하면서 입력됩니다.
    이 경우 a컬럼을 클러스터 인덱스로 설정할때 DESC로 설정하면, 데이터가 계속 맨앞의 페이지에 쌓인다거나 해서 페이지 분할이나 인덱스 조각화의 문제점은 없을까요?

    추가)

    a컬럼 identity(1,1)

    b컬럼 int

    테스트 테이블 생성 후 클러스터 인덱스 생성 시 a컬럼을 asc로 생성 후 데이터를 삽입하면 인덱스 조각화가

    거의 일어나지 않지만, desc로 생성 후 삽입하면 조각화가 엄청나게 일어나네요

    2020년 6월 22일 월요일 오전 12:29

모든 응답

  • identity 키 칼럼을 클러스터드 인덱스로 정하고, 정렬순서를 asc로 하건, desc로 하건, select시에는 그 차이는 없을 겁니다. 

    클러스터드 인덱스는 대체로 1, 값이 유니크하고, 2, 차지하는 용량이 가능한 작고, 3, 값이 바뀌지 않으며, 4, 값이 계속 증가하는 칼럼에 만듭니다. 클러스터드 인덱스는 키순으로 데이타가 정렬되고 리프페이지에는 실제 데이타가 키순으로 저장되어 있습니다.

    페이지 분할은 여유 공간이 해당 페이지에 없을때, 일어나죠.

    identity 칼럼의 씨드값을 1로, 증가값을 1로 했다면, 중간에 어떤 값이 끼어들수가 없습니다. 따라서, 페이지 분할이 insert 작업으로는 일어나지 않죠. delete 작업의 경우도 역시, 페이지 분할은 일어나지 않을 겁니다. 그러면 updae작업인데, 페이지가 100% 찼을경우, varchar같은 일반 칼럼에  기존보다 큰 값으로 업데이트 한다면, 페이지 분할이  일어나고, 자주 update가 발생한다면, 인덱스까지도 분할이 일어날것이라고 봅니다.

    그런데, identity 칼럼에 클러스터드 인덱스를 만들고, desc로 정렬 순서를 줬다면, insert이 있을때마다, 첫페이지에서는 지속적인 reorg작업이 있을테고, 페이지 크기가 8k라는 것을 감안한다면, insert 작업이 자주 일어나는 환경이라면, 처음엔, 8k 단위로 페이지 분할이 일어났다가, 그 후엔 4k 단위로 페이지 분할이 일어날겁니다. 상위 레벨의 페이지들도 마찬가지겠죠.

    첫 줄에서 말씀드렸다시피, 최근 데이타를 먼저 보여주기 위해 클러스터드 인덱스를 desc로 생성했다면, 씨퀄 서버는 찾기방향을 backward를 지원하므로, 안심하고, asc를 사용해도 될걸로 보입니다. 

    desc로 생성해서 몇번의 insert가 없었는데, 계속 페이지 분할을 일으키는 것보다는 나을겁니다.

    이진우.

    2020년 6월 22일 월요일 오전 7:16
  • 클러스터형 인덱스를 사용하는 경우 모든 삽입은 테이블 순서를 변경합니다. asc를 사용하면 거의 변경되지 않으므로 삽입 순서는 id (1,2,3,4 ……)로 됩니다.

    desc를 사용하는 동안 첫 번째 행은 1이며, 2를 삽입하면 순서를 (2,1)로 변경해야 하며 3을 삽입하면 순서가 (3,2,1)로 변경되어 대랑의 조각화가 발생합니다.

    그래서 단일 열 인덱스를 asc 또는 desc으로 만드는 것에 대해 걱정하지 않아도 됩니다. (ID desc로 열 순서 선택할수 있습니다).

    MSDN Community Support Ricky

    다른 커뮤니티 멤버에게 도움이 될 수 있게 문제를 해결 한 답변을 '답변으로 표시'를 클릭하시고 그렇지 않은 경우 '답변으로 표시 취소'를 클릭하시기 바랍니다. MSDN 서포트에 대한 의견이나 불만이 있을 경우 MSDNFSF@microsoft.com 으로 연락하시기 바랍니다.

    2020년 6월 22일 월요일 오전 10:33
    중재자