인덱스 구조 분석

 

DBA 업무시작 시기 (18년도 즈음)에 정리했던 자료로 재검증 안함 

 

1.인덱스 페이지 구조

2.인덱스 구조 해부 

2.1. 사전 준비

 

2.2. 단일익스텐트와 혼합익스텐트

2.2.1. 혼합익스텐트

• 페이지만 할당하였기 때문에 Total_pages 2개
• Used_pages가 2개인 이유 : 힙은 IAM(Index allocation map) page를 갖게 됨
• 8KB의 데이터페이지(0x5) 1개에 Row 1개 확인
• 데이터 페이지 (0x5A00~)/ IAM (0x5D00~)

2.2.2. 단일익스텐트

2.3. 데이터 삽입에 따른 페이지 분할 (혼합 익스텐트 O)

• Used_pages가 2개인 이유 : 힙은 IAM(Index allocation map) page를 갖게 됨
• 8KB의 데이터페이지(0x5) 1개에 Row 1개 확인
• 데이터 페이지 (0x5A00~)/ IAM (0x5D00~)

• 총 7개 Row 삽입으로 1개의 데이터페이지 존재

• 총 삽입된 데이터 9KB로 인하여 데이터페이지 1개 추가 생성

2.4. 페이지 정보 조회

2.4.1. 힙 First Data 페이지 조회 (혼합 익스텐트)

• First Data 페이지 내 정보
  •  Slot : 페이지 내 Row 번호 / Record Size : 해당 Row의 크기
     S0001AA… : 해당 Slot 삽입 데이터
     OFFSET TABLE : 페이지 내 Row의 위치 정보
    

2.4.2. 클러스터 인덱스 Fisrt Data 페이지 조회 (혼합 익스텐트) 

•  Index_id : 1 = 클러스터 인덱스

• 항목 2.4.1. 과 같이 1KB Row 7건 삽입 (A~G)

• 데이터 삽입으로 인한 Second_page와 클러스터 인덱스 Root 페이지 (0x5A) 생성
  • 클러스터 인덱스 Root 페이지 : 정렬된 클인 페이지의 첫 정렬 컬럼값을 기록

• First 페이지의 Second 페이지 주소 (m_nextPage 93) 확인
• Row-Offset과 m_slotCnt를 통해 입력된 Row 개수 확인

• Second 페이지가 마지막 페이지 (m_nextpage 0)/ 이전 페이지 80 (m_prevPage)
• 삽입된 Row 1개/ 우측 삽입된 데이터 정보 (SOOO8,HHH..)

• Root Page는 Intermidiate Page 없음 (m_nextPage 0)
• Slot에 페이지 별 첫 데이터 S0008삽입됨을 확인 (인덱스 컬럼 col1)

• 클러스터 인덱스도 실제 물리적으로는 정렬 안됨/ Offset을 통해 빠르게 서칭

2.4.3. 페이지 분할 (항목 2.4.2.의 T1 계속 진행)

• 수행 전 : Fisrt Page(0x80) : S0001~S0007, ABCDEFG / Second Page(0x93) : S0008~S0009,HI
  • First Page에 Row가 꽉 참

• Fisrt Page 조회 결과 : Second page 0x93->0x94 변경
• 수행 후 : Fisrt Page(0x80) : (S0001~S0004,A~D)

• Second Page 조회 결과 : Third Page 생성 (기존 Second P였던 0x93)
• 수행 후 : Second Page(0x94) :  (S0005~S0007,E~G)

• Third Page 조회 결과 : Last Page

• 수행 후 : Last Pgae (0x93) : (S0008~S0011,H~K)

• Root Page의 기록 값은 S0005, S0008
  • 클러스터 인덱스 페이지들의 첫번째 데이터

• 페이지 내에서는 정렬이 안됨 / 중간값 삽입시 해당 값 기준으로 앞 뒤 데이터들이 페이지 분할

• 인덱스 페이지가 꽉찼을때 중간에 데이터 삽입이 필요할 경우, 해당 row부터 새로운 페이지로 분할 : 클인에서 Insert의 문제점