https://coding-factory.tistory.com/419
코딩 펙토리 님의 글을 기록한 것임을 밝힙니다.
인덱스(Index)란?
인덱스는 데이터베이스 테이블에 있는 데이터를 빨리 찾기 위한 용도의 데이터베이스 객체이며 일종의 색인기술입니다. 테이블에 index를 생성하게 되면 index Table을 생성해 관리합니다. 인덱스는 테이블에 있는 하나이상의 컬럼으로 만들 수 있습니다. 가장 일반적인 B-tree 인덱스는 인덱스 키(인덱스로 만들 테이블의 컬럼 값)와 이 키에 해당하는 컬럼 값을 가진 테이블의 로우가 저장된 주소 값으로 구성됩니다.
스스로 이해하기를 책으로 이해했다. 책에 붙여놓은 색인과 그를 이용해 바로 페이지를 펼친다고 생각하고 있다.
그렇다면 분명 바로 펼쳐볼 수 있게 각 인덱스 내부에는 주소값이 있으리라, 하고 생각한다.
▶인덱스(Index) 사용 예시
인덱스 생성
--문법
CREATE INDEX [인덱스명] ON [테이블명](컬럼1, 컬럼2, 컬럼3.......)
--예제
CREATE INDEX EX_INDEX ON CUSTOMERS(NAME,ADDRESS);
--예제 컬럼 중복 X
CREATE[UNIQUE] INDEX EX_INDEX ON CUSTOMERS(NAME,ADDRESS);
위와같이 쿼리문을 작성하면 INDEX를 생성할 수 있습니다. UNIQUE 키워드를 붙이면 컬럼값에 중복값을 허용하지 않는다는 뜻입니다.
컬럼에 따른 인덱스를 추가한다고 본다. 컬럼 데이터(페이지) 에 대한 주소 값을 달아주었다.. 라고 생각하고 있다. 그렇다면 데이터베이스는 실행계획을 짤 때에 FullScan하지 않을테고, 정렬 순서도 인덱스에서 자동으로 정렬된 순서를 따라 RowId 를 찾아 데이터를 뽑아내는 과정을 반복하니까, 정렬도 하지 않을 수 있구나. 한다.
인덱스를 생성하면 USER_INDEXES 시스템 뷰에서 조회할 수 있습니다.
SELECT * FROM USER_INDEXES WHERE TABLE_NAME = 'CUSTOMERS';
인덱스의 삭제
DROP INDEX [인덱스 명]
인덱스는 조회성능을 극대화하기 위해 만든 객체인데 너무 많이 만들면 insert, delete, update시에 부하가 발생해 전체적인 데이터베이스 성능을 저하합니다. 고로 안쓰는 인덱스는 삭제시키는것이 좋습니다.
인덱스를 리빌드하는 이유
인덱스 파일은 생성 후 insert, update, delete등을 반복하다보면 성능이 저하됩니다. 생성된 인덱스는 트리구조를 가집니다. 삽입,수정,삭제등이 오랫동안 일어나다보면 트리의 한쪽이 무거워져 전체적으로 트리의 깊이가 깊어집니다. 이러한 현상으로 인해 인덱스의 검색속도가 떨어지므로 주기적으로 리빌딩하는 작업을 거치는것이 좋습니다.
SELECT I.TABLESPACE_NAME,I.TABLE_NAME,I.INDEX_NAME, I.BLEVEL,
DECODE(SIGN(NVL(I.BLEVEL,99)-3),1,DECODE(NVL(I.BLEVEL,99),99,'?','Rebuild'),'Check') CNF
FROM USER_INDEXES I
WHERE I.BLEVEL > 4
ORDER BY I.BLEVEL DESC
해당쿼리는 index 트리의 깊이가 4이상인 index를 조회하는 쿼리입니다. 해당 쿼리문을 실행하여 검색되는 index가 있다면 리빌딩을 하는것이 좋습니다.
ALTER INDEX [인덱스명] REBUILD;
위의 쿼리를 실행시키면 인덱스가 리빌드 됩니다. 이렇게 일일히 리빌드 시키기 귀찮으신 분들은 USER_INDEXES에 있는 인덱스를 조회하여 인덱스 리빌드 쿼리를 만들어 한번에 실행시키시면 간편합니다.
SELECT 'ALTER INDEX '||INDEX_NAME||' REBUILD; 'FROM USER_INDEXES;
제대로 이해하고 있는 게 맞나 싶은데, 인덱스 값에 맞는 RowId를 가진 데이터들을 추가, 삭제, 수정 되는 과정을 거치면서 데이터가 없거나 추가되거나 수정되면서 트리의 구조가 한 쪽으로 치우쳐 남아있게 되어버린 듯 하다. 삭제하면..인덱스는 남아있구나...하는 생각을 해보고 있다. 그렇기에 리빌드해서 없거나 불필요한 인덱스 주소 값들은 쳐내고, 다시 트리구조의 균형을 잡아주는게 리빌딩 작업이 아닐까...하고 조심스레 생각해본다.
인덱스(Index)를 남발하지 말아야 하는 이유
개발을 진행할때에 대개 개발서버와 운영서버를 나누어서 관리합니다. 대부분 개발서버에서 개발을 할때에는 적은량의 데이터를 가지고 로직검사를 하며 로직검사에 통과한 코드들이 운영서버에 업데이트가 되죠. 하지만 개발서버에는 잘 동작하던 로직들이 운영서버의 많은량의 데이터들을 처리하다보면 성능이슈가 많이 발생합니다. 그 성능이슈의 주요원인은 바로 데이터베이스에 있습니다. 데이터베이스 관리자는 성능문제가 발생하면 가장 빨리 생각하는 해결책이 인덱스 추가 생성입니다. 그렇게 하여 인덱스를 하나 만들었다고 합시다. 그리고 또 다른 SQL에서문에서 성능이슈가 발생하여 또 인덱스를 만들었다고 합시다. 이렇게 문제가 발생할때마다 인덱스를 생성하면서 인덱스가 쌓여가는것은 결코 좋지않습니다. 인덱스를 만드는것은 하나의 쿼리문을 빠르게는 만들 수 있지만 전체적인 데이터베이스의 성능 부하를 초래합니다. 그렇기에 인덱스를 생성하는것 보다는 SQL문을 좀 더 효율적으로 짜는 방향으로 나가야합니다. 인덱스생성은 꼭 마지막 수단으로 강구해야 할 문제입니다.
여기까지 오늘 공부하면서 궁금한 내용을 알아보았다. 진심으로 감사의 말씀을 드리면서, 문제가 있을시 언제든 삭제하도록 하겠습니다.
'공룡이라는 ORACLE' 카테고리의 다른 글
다중 insert 시 시퀀스 넘버가 PK 제약조건을 어긋내는 경우 해결방안. (0) | 2020.10.20 |
---|---|
TopN (0) | 2020.10.06 |
간단한 백업 (0) | 2020.10.03 |
설계, 향후 추가 (0) | 2020.09.24 |
강사님께 제공받은 64진수 변환 프로시저 (0) | 2020.09.08 |