티스토리 뷰
반응형
잘 해보려고 하지만 또 잘 안되는게 있다면
'지식의 정리' 이다.
요즘은 바로 얼마전 일도 가물가물하기 때문에
더욱더 절실히 느끼는 바이다. ㅎㅎㅎ
이것이 내게는 포스팅을 하는 원동력이다.
그리고 간혹가다가 내가 정리한 글을 읽고
도움이 되었다며 남겨주는
누군가의 짧은 말한마디의 희열도. ^^
지난번 까지 인덱스가 무엇인지 그리고 기본적인 사항에 대해서
두번에 걸쳐 짧게나마 소개를 했고, 이제부터는 좀 본격적인 이야기를 해 보도록 하겠다.
인덱스는 크게 두가지로 나눌 수가 있다. 그리고 이것은 책에 비유해서 설명하면 이해가 아주 쉽다.
1. 클러스터 인덱스(Clustered Index)
클러스터 인덱스의 경우는 책의 맨앞에 나와있는 '차례'와 같은 놈이다.
클러스터 인덱스의 경우는 책의 맨앞에 나와있는 '차례'와 같은 놈이다.
예를 들어
DB책에서 테이블을 만드는 법에 대해서 찾고싶다고 가정해 보자.
먼저 책의 맨앞의 차례를 펼치고 테이블 관련 챕터가 있는지 훑어본 다음, 찾았다면
테이블 챕터 하위에 자신이 생각한 검색어(예를들어 '테이블을 만드는 문법')와 가장 흡사한
장을 찾아서 해당 페이지로 이동하는 것이 가장 빠른 방법일 것이다.
머리속에 이미지가 새겨지는지? 헷갈린다면 지금 주위에 있는 아무 책이라도 차례를 펼쳐보기 바란다.
검색결과가 상당히 빠를 것이다. 이것이 클러스터 인덱스의 검색방법이다.
그럼 조금만 더 들어가서 생각을 해 보도록 하자.
만약에 책의 내용이 추가되어서, 이미 마련되어 있는 차례를 수정해야 할 경우에는 어떨까.
그것도 차례 중간에 내용이 추가되어야 한다면 좀 골치가 아파진다. 이미 페이지순서가 정해져 있는데
중간에 내용을 삽입한다면 그 뒤로 나오는 인덱스는 페이지 번호를 전부 수정해야 할 것이다.
그래서 클러스터 인덱스를 생성함에 있어서는 항상 신중을 기해야 한다.
그럼 조금만 더 들어가서 생각을 해 보도록 하자.
만약에 책의 내용이 추가되어서, 이미 마련되어 있는 차례를 수정해야 할 경우에는 어떨까.
그것도 차례 중간에 내용이 추가되어야 한다면 좀 골치가 아파진다. 이미 페이지순서가 정해져 있는데
중간에 내용을 삽입한다면 그 뒤로 나오는 인덱스는 페이지 번호를 전부 수정해야 할 것이다.
그래서 클러스터 인덱스를 생성함에 있어서는 항상 신중을 기해야 한다.
클러스터 인덱스의 특징으로는
1. 책의 차례와 마찬가지로 테이블당 한개밖에 만들지 못한다.
2. PK를 설정하면 자동으로 클러스터 인덱스가 생성된다.(비클러스터 형으로 변환도 가능하다.)
3. 클러스터 인덱스를 생성하더라도 PK가 되는 것은 아니다.
4. delete, update 속도에 영향을 미치지만 특히 insert에 큰 영향을 미친다.
5. 차례와 같이 순서가 동일하기 때문에 범위를 주고 찾는 경우 탁월한 성능향상을 기대할 수 있다.
6. 하나의 값을 조건으로 검색하더라도 빠른 결과를 얻을 수 있다.
2. PK를 설정하면 자동으로 클러스터 인덱스가 생성된다.(비클러스터 형으로 변환도 가능하다.)
3. 클러스터 인덱스를 생성하더라도 PK가 되는 것은 아니다.
4. delete, update 속도에 영향을 미치지만 특히 insert에 큰 영향을 미친다.
5. 차례와 같이 순서가 동일하기 때문에 범위를 주고 찾는 경우 탁월한 성능향상을 기대할 수 있다.
6. 하나의 값을 조건으로 검색하더라도 빠른 결과를 얻을 수 있다.
2. 비클러스터 인덱스(NonClustered Index)
비클러스터 인덱스를 이해하기에 가장 쉬운 방법중 하나는 책의 맨 뒤에 있는 '찾아보기'를 떠올리는 것이다.
예를 들어보자.
역시나 DB책에서 검색을 하고자 한다. 키워드는 '차등백업'이라고 하자.
이번에는 책의 맨 뒤에 있는 찾아보기 페이지에 가서 'ㅊ'으로 시작하는 항목을 살펴본다.
그리고 차등백업이란 단어를 찾아서 해당 페이지로 이동하는 것이 가장 빠른 방법이 될 것이다.
와...
무식할만큼 두꺼운 DB 책속에서 차등백업을 설명하는 페이지를 찾는데 단 몇초밖에 걸리지 않았다.
(실제로 옆에 있는 아무 책이나 찾아보시길... 진짜로 10초 이내로 찾을 수 있다.)
인덱스란 놈은 너무나도 효율적이고 select에게 있어서 효자일지도 모른다고 느끼기 시작하기까지 한다.
.
.
.
그럼 이런 경우에는 어떨까.
이번에는 '테이블'이란 키워드로 찾아보기에서 검색해 보도록 하자.
결과는 어떨까.
DB책의 특성상 '테이블'이란 키워드는 책의 전체 페이지에 상당히 많이 거론될 것이다.
그렇기 때문에 인덱스 한번보고, 페이지 한번보고, 인덱스 한번보고, 페이지 한번보고......반복x반복.....
어떤가. 이런경우에도 과연 인덱스가 select의 효자라고 이야기할만 할까. 이 경우는 불효자가 따로없다. ㅎㅎ
비클러스터 인덱스의 특징
1. 책의 찾아보기와 마찬가지로 테이블당 여러개의 인덱스가 생성가능하다.
2. UNIQUE 제약조건을 걸면 자동으로 생성된다.(클러스터형으로 변환도 가능하다.)
3. delete, update, insert의 속도에 영향을 미치지만 클러스터 인덱스만큼은 아니다.
4. 유니크한 키워드로 검색할 경우 속도가 빠르다.(그래도 클러스터보다는 약간 느림)
5. 중복된 데이터가 많을 경우 비클러스터 인덱스로 설정하면 오히려 안좋다.
6. 범위를 주고 검색할 경우에도 역시 안하느니만 못하다.(인덱스 없이 테이블 스캔이 더 빠르다.)
7. 커버된 색인(Covered Index)의 경우 클러스터 색인보다 월등히 빠른 결과를 가져온다.
비클러스터 인덱스를 이해하기에 가장 쉬운 방법중 하나는 책의 맨 뒤에 있는 '찾아보기'를 떠올리는 것이다.
예를 들어보자.
역시나 DB책에서 검색을 하고자 한다. 키워드는 '차등백업'이라고 하자.
이번에는 책의 맨 뒤에 있는 찾아보기 페이지에 가서 'ㅊ'으로 시작하는 항목을 살펴본다.
그리고 차등백업이란 단어를 찾아서 해당 페이지로 이동하는 것이 가장 빠른 방법이 될 것이다.
와...
무식할만큼 두꺼운 DB 책속에서 차등백업을 설명하는 페이지를 찾는데 단 몇초밖에 걸리지 않았다.
(실제로 옆에 있는 아무 책이나 찾아보시길... 진짜로 10초 이내로 찾을 수 있다.)
인덱스란 놈은 너무나도 효율적이고 select에게 있어서 효자일지도 모른다고 느끼기 시작하기까지 한다.
.
.
.
그럼 이런 경우에는 어떨까.
이번에는 '테이블'이란 키워드로 찾아보기에서 검색해 보도록 하자.
결과는 어떨까.
DB책의 특성상 '테이블'이란 키워드는 책의 전체 페이지에 상당히 많이 거론될 것이다.
그렇기 때문에 인덱스 한번보고, 페이지 한번보고, 인덱스 한번보고, 페이지 한번보고......반복x반복.....
어떤가. 이런경우에도 과연 인덱스가 select의 효자라고 이야기할만 할까. 이 경우는 불효자가 따로없다. ㅎㅎ
비클러스터 인덱스의 특징
1. 책의 찾아보기와 마찬가지로 테이블당 여러개의 인덱스가 생성가능하다.
2. UNIQUE 제약조건을 걸면 자동으로 생성된다.(클러스터형으로 변환도 가능하다.)
3. delete, update, insert의 속도에 영향을 미치지만 클러스터 인덱스만큼은 아니다.
4. 유니크한 키워드로 검색할 경우 속도가 빠르다.(그래도 클러스터보다는 약간 느림)
5. 중복된 데이터가 많을 경우 비클러스터 인덱스로 설정하면 오히려 안좋다.
6. 범위를 주고 검색할 경우에도 역시 안하느니만 못하다.(인덱스 없이 테이블 스캔이 더 빠르다.)
7. 커버된 색인(Covered Index)의 경우 클러스터 색인보다 월등히 빠른 결과를 가져온다.
인덱스들의 종류와 특징에 대해서 정리를 해보았다.
업무를 해 오면서 느꼈던 것들을 나름대로 DB관련 서적의 내용과 비교해 가며 검증을 해 보았는데
글을 쓰면서 나의 주관적인 생각들이 많이 들어갔기 때문에 위 내용을 절대적으로 생각하지 말았으면 한다. ㅎㅎ
그리고 노파심에 중요한 점 한가지를 더 말하자면
인덱스 튜닝작업은 데이터 양이 많을 경우 퍼포먼스에 상당한 영향을 끼친다.
다시말해 시스템이 엄청나게 느려져서 사용자 입장에서는 마치 멈춘 것처럼 느낄 수도 있다는 이야기다.
그렇기 때문에 업무시간에 실제 DB의 인덱스를 생성하거나, 튜닝하는 작업을 하는 것은
유저들의 원성(폭동) 혹은 관리자 사수로부터 엄청난 갈굼이 따를 수도 있는 등
심각한 상황이 발생할 수도 있다는 것을 명심해야 한다. ㅎㅎㅎ
일이 심각해져서....
요렇게 될 수도 있다는 얘기다....
인덱스 튜닝작업은 데이터 양이 많을 경우 퍼포먼스에 상당한 영향을 끼친다.
다시말해 시스템이 엄청나게 느려져서 사용자 입장에서는 마치 멈춘 것처럼 느낄 수도 있다는 이야기다.
그렇기 때문에 업무시간에 실제 DB의 인덱스를 생성하거나, 튜닝하는 작업을 하는 것은
유저들의 원성(폭동) 혹은 관리자 사수로부터 엄청난 갈굼이 따를 수도 있는 등
심각한 상황이 발생할 수도 있다는 것을 명심해야 한다. ㅎㅎㅎ
일이 심각해져서....
요렇게 될 수도 있다는 얘기다....
이전글을 보시려면 아래링크 클릭 ↓↓
2009/09/17 - [DB(MS, PG, MY..etc)] - SQL 이야기 - Index(색인)에 대해서
2009/09/22 - [DB(MS, PG, MY..etc)] - 색인(Index)의 기본개념에 대해서
반응형
'DB(MS, Oracle, PG, MY..etc)' 카테고리의 다른 글
인덱스 재구성 메인터넌스 에러 - 페이지 잠금수준 - 해결방법 (0) | 2010.11.16 |
---|---|
대체 왜? Select는 좋고, Insert에는 안좋을까? - 인덱스의 내부 작동방식 (6) | 2009.10.06 |
색인(Index)의 기본개념에 대해서 (2) | 2009.09.22 |
SQL 이야기 - Index(색인)에 대해서 (0) | 2009.09.17 |
나도 옛날사람? ㅎㅎ MySQL의 GUI툴 간략한 소개 (2) | 2009.09.02 |
댓글
반응형
12-03 08:04
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- brawlstars
- 8비트상성
- 고전명작
- 추억의 게임
- 플래쉬 게임
- 오락실게임
- XML Programming with VB 6.0
- xml강좌
- MS-SQL
- J.S Bach
- c#
- 플래쉬게임
- 좀비게임
- 플래시
- 다른그림찾기
- 플래시 게임
- 브롤스타즈
- 플래시게임
- 틀린그림찾기
- Excel
- 레트로게임
- C
- 중독성짱게임
- 고전게임
- 엑셀
- SQL
- 오락실 게임
- XML
- 플래쉬
- 8비트
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
글 보관함