티스토리 뷰
CI의 정렬 기준으로 실제 데이터를 정렬해 둡니다. 데이터를 찾을 때 CI를 타느냐, 테이블 스캔 하느냐의 차이만 존재합니다.
1-2. 구조
루트페이지와 리프페이지의 2중 구조
루트페이지에는 검색기준이 리프페이지에는 실제 데이터가 검색기준에 맞쳐 분류되어있음
쿼리시 루트 페이지에서 해당 검색기준을 통해 리프페이지(실제데이터)를 검색하여 결과처리
데이터 변경작업시 루트페이지에 맞쳐서 리프페이지를 다시 분류작업함
2. Non-Clustered Index만 존재했을 때
이 경우 NI의 키 값 대로 정렬된 데이터가 존재하고, 키 값에 대응하는 실제 데이터의 주소 (파일, 페이지, 행번호) 를 가집니다.
NI에서의 키 값에 매칭되는 값을 찾은 후, 실제 데이터를 찾아가는 과정만큼의 비용이 필요합니다.
이 비용이 크기 때문에, 일반적으로 NI를 이용해서 찾는 데이터가 전체 데이터의 3~5%이내 일 때만 NI를 이용하고, 그렇지 아닐 경우 테이블 스캔을 합니다.
2-1. 구조
루트페이지와 리프페이지. 실제데이터의 3중구조.
루트페이지에는 검색기준, 리프레이지에는 실제데이터를 참조한 분류 ,실제데이터에는 데이터
select 시에는 3중구조임으로 클러스터형 인텍스보다 비효율적임
그러나. 데이터 변경작업시에는 실제데이터에는 변경이 없음으로 클러스터형 보다 효율적.
3. Non-Clustered Index와 Clustered Index 공존시
이 경우 NI가 실제 데이터의 행번호를 가리키는 것이 아니라, CI의 키 값을 가리킵니다.
장점은 CI가 변경될 때, NI에 적은 영향을 줍니다. (CI로 정렬 되어 있는 만큼, 테이블 중간에 데이터가 끼어들거나 삭제되면 페이지 분할등이 일어나 행번호가 바뀔여지가 있습니다. 행번호가 바뀌어도 행번호가 아니라, CI의 키 값을 가리키기 때문에 NI에 적은 영향만을 주고 데이터를 변경할 수 있게 됩니다.)
3-1. 구조
루트페이지(비클러스터형) -> 리프페이지 (비클러스터형) -> 루트페이지 (클러스트형) -> 리프페이지 (클러스트형) 의 4중구조 (실제데이터는 리프페이지 - 클러스트형)
'Database > General' 카테고리의 다른 글
서버에서 데이터 베이스 이용시 유의 사항 (0) | 2010.08.13 |
---|---|
데이터 결합 (JOIN) 방법 정리 (0) | 2009.03.26 |
인덱스 정리 (0) | 2009.03.26 |
인덱스가 있지만 인덱스를 안 타는 경우 (0) | 2009.03.26 |
OLE DB 기본 사용법 (2) | 2008.08.08 |
- Total
- Today
- Yesterday
- 리버스 엔지니어링
- ftp
- svn
- 게임데브포에버
- c언어
- SDL
- 루비
- CppSQLite
- TDD
- RoR
- perfmon
- EasyExec
- TraceRoute
- NDC2013
- ruby
- 루비 온 레일즈
- 디버깅
- 조엘 온 소프트웨어
- EzShortcut
- 바로가기 프로그램
- 멀티스레드
- 엘키
- 좋은 프로그래머
- Ruby on Rails
- 디자인 패턴
- 게임개발포에버
- MS-SQL
- 임백준
- Rails
- SQLite Spy
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |