그래서 서비스상태에서는 인덱스를 주면 장애가 날수 있습니다.
Index 정의
1) 조회속도를 향상시키기 위한 데이터베이스 검색 기술
2) 색인이라는 뜻으로 해당 테이블의 조회결과를 빠르게 하기 위해 사용합니다.
보통 INDEX를 테이블의 특정 컬럼에 한개이상을 주게 되면 Index table 이 따로 만들지는데
이 INDEX table 에는 인덱스컬럼의 로우의 값과 rowid 값이 저장되게 되며 로우의값은 정렬된 B-TREE 구조로 저장시켜두어 검색시 좀더 빠르게 해당 데이타를 찾는데 도움을 준다.
하지만 UPDATE,INSERT,DELETE 시에 속도가 느려진다는 단점이 있다.
왜냐하면 INSERT, UPDATE, DELETE 시에는 원본TABLE은 물론 INDEX table 에도 데이타를 갱신시켜 주어야 하기 때문입니다.
하지만 너무 작은 로우(레코드)가 있는 TABLE에 INDEX를 사용하게 되면 index의 효력을 제대로 발휘못하며 반드시 INDEX키를 조건으로 검색시에는 연산이나 가공을 하면 INDEX를 탈수없다.
※ 테이블을 생성하고 컬럼을 만든후 데이타를 삽입하면 하나의 로우가 생성되며 이 로우는 절대적인 주소를 가지게 됩니다. 이 절대적인 주소를 ROWID 라고 합니다.
INDEX가 필요한 이유?
조회 속도를 최대한 줄일수 있다.
참고
인덱스를 만들 때 현재 컬럼수가 너무 많으면 DML의 성능이 떨어지고 너무 부족하면
쿼리의 성능이 떨어집니다. 데이터가 많고 B*Tree Index인 경우 컬럼level이 하나
늘어날 때 그에 따른 node의 추가가 엄청나게 일어날 수 있습니다
이런 node들이 너무 많으면 쿼리성능도 좋을 수 없습니다.
인덱스는 일반적으로 최대 5개 컬럼 내외정도로 상황에 따라 합리적으로 구성합니다.
INDEX가 필요한 경우?
1) 데이터가 적은(수천건 이상) 경우이거나 조회속도가 너무 느리면 인덱스를 설정하는
것이 성능이 좋습니다.
2) 조회결과가 전체 데이타수의 3~5% 미만일 경우에 인덱스스캔이 효율적이고
적은비용으로 빠르게 데이터를 찾아낼수있습니다.
하지만 Acess 대상범위가 전체범위의 3~5%이상쯤 되면 인덱스스캔 보다 풀스캔이 휠씬
유리합니다.
인덱스 스캔 = Index Scan
풀 스캔 = Full Scan
INDEX가 불필요한 경우?
1) 데이터가 적은(수천건 미만) 경우에는 인덱스를 설정하지 않는게 오히려 성능이 좋습니다.
2) 조회 보다 삽입, 수정, 삭제 처리가 많은 테이블
3) 조회결과가 전체행의 15% 이상 읽어들일것으로 예상될때
Index 튜닝의 시기단계
하드웨어
DBMS 환경체크 - INDEX설정 및 파티셔닝체크 - SQL최적화 등의 레벨 순서로 튜닝합니다.
소프트웨어
쿼리문의 조회조건이 인덱스를 타는지 체크한다.(조금 중요)
쿼리문의 JOIN키가 모두 INDEX 설정이 되어 있는지 체크한다. INDEX설정이 되어 있지 않는 컬럼을 JOIN키로 지정했다면 조회속도가 많이 느려질수 있다.(많이 중요)
INDEX 생성하는 방법?
자동 생성
유일 인덱스는 테이블 정의시 PRIMARY KEY와 UNIQUE KEY 제약조건을 정의할때 자동으로 생성한다.
수동 생성
사용자는 행에 대한 액세스 시간을 향상 시키기 위해 열에서 유일하지 않은 인덱스를 생성할수 있다.
INDEX 생성 문법?
사용형식
CREATE INDEX index_name ON table_name (column_name)
--단일 인덱스 지정
CREATE INDEX index_name ON table_name (column_name1,column_name2,column_name3)
--다중 인덱스(복합 인덱스) 지정
※ 복합 인덱스로 지정해준 테이블에서 복합 인덱스를 타게 하려면 복합 인덱스로 준 컬럼
을 조회쿼리에서 모두 조회조건에 사용해야 인덱스를 탈 확률이 높아진다.
사용예제
create index index_a_date on account(a_date);
create index index_a_date on account(a_date, b_date, c_date);
※ null 허용 컬럼은 인덱스를 만들수 없습니다.
INDEX 가능 컬럼
인덱스는 모든 컬럼에 적용가능하다.
그런데 오라클은 가공시킨 컬럼에도 적용가능하다. 아래 참고
CREATE INDEX IDX_NAME ON TABLE_NAME(ROUND(PRICE1-PRICE2));
ROUND(PRICE1-PRICE2) 는 컬럼은 아니지만 컬럼을 가공해서 만든것이다.
이런 가공컬럼은 다음과 같은 SQL 쿼리로 인덱스를 탈수 있다.
SELECT * FROM TABLE_NAME WHERE ROUND(PRICE1-PRICE2) > 0
※ 인덱스 줄때의 가공컬럼과 같아야 합니다.
SQL 쿼리의 INDEX SCAN 유무 체크 방법
1. 상용 DB 관리도구를 이용하는 방법
PL/SQL Developer, Toad 같은 도구에서 SQL문을 작성하고 실행하면 Explain plan 에서 확인 가능합니다.
INDEX를 사용해야할 컬럼은?
where절이나 조인 조건에서 자주 사용되는 열에 생성
열은 광범위한 값을 포함할때
열은 많은수의 null값을 포함할때
조회결과가 전체행의 2-4% 보다 적게 읽어들일것으로 예상될때
--테이블이 클때 적은 양의 로우를 검색할때 인덱스를 줍니다. 적은 양을 검색하는데 테이블을 전체 풀스캔하면 시간이 오래 걸려서 꼭 index를 줘야 합니다.
INDEX를 사용하지 말아야할 컬럼은?
테이블에 데이타가 작은 경우
where절에 자주 사용되지 않는 열은 사용되지 않는다.
조회결과가 전체행의 2-4% 이상을 읽어들일것으로 예상될때
테이블이 자주 갱신된다.
INDEX 생성시 고려사항?
고려사항
인덱스가 적용된 컬럼이 조건식에서 인덱스를 탈수있게 하려면 해당컬럼을 가공하지않거나 연산을 하지 않은 상태에서 비교해야 인덱스를 탑니다.
예를들어 연락처컬럼의경우(016-293-1965) 016 만 따로 문자열을 잘라(가공) 조건검색하면 인덱스를 타지 않습니다.
왜냐하면 인덱스 컬럼에 변형이 일어나면 상대값과 비교되기 전에 먼저 가공이 된 후에 비교된다.하지만 인덱스는 가공되기 전의 값으로 생성되어 있기 때문에 당연히 인덱스를 사용할 수 없게 된다. 여기에서 외부적(External) 변형이란 사용자가 인덱스를 가진 컬럼을 어떤 SQL함수나 사용자 지정함수(User Defined Stored Function), 연산, 결합(||) 등으로 가공을 시킨 후에 발생되는 것이며 이러한 경우는 인덱스를 탈수 없어 변형이 일어나지 않도록 제대로 기술해야 합니다.
그렇기때문에 016과 293과 1965를 각각의 컬럼으로 만들어 저장한후 각각의 컬럼에 인덱스를 주면
아무런 가공없이 조건 검색이 가능하므로 인덱스를 탈수 있습니다.
테이블 컬럼에 인덱스가 있따면 테이블 컬럼을 변경하는것보다 비교값을 변경하여
비교해주는데 좋다. 왜냐면 그래야 인덱스를 타기 때문이다.
WHERE to_char(joindate, 'yyyymmdd') = '20070612'
WHERE joindate = TO_DATE('20070612','yyyymmdd')
아래는 인덱스를 타지 않습니다.
SELECT * FROM ACCOUNT WHERE A_DAY+1>2;
SELECT * FROM ACCOUNT WHERE SUBSTR(A_STRDAY,1,1)='월';
SELECT * FROM EMP WHERE EMP_ID = NVL(EMP_ID,'10');
아래는 인덱스를 탑니다.
SELECT * FROM ACCOUNT WHERE A_STRDAY='월요일';
SELECT * FROM ACCOUNT WHERE A_DAY>2;
SELECT * FROM EMP WHERE EMP_ID = NVL('10','20');
SELECT * FROM ACCOUNT WHERE A_STRDAY like '월요일%';
※ 첫번째 쿼리부터 인덱스효과가 크게 나타나는 순입니다.
INDEX 타는 경우와 안타는 경우
안타는 경우
1. SELECT * FROM emp WHERE empno <> '7369';
※ 오라클에서는 인덱스 타게 가능(exists 이용)
SELECT * FROM emp WHERE not exists
(select empno FROM emp WHERE empno = '7369' and a.empno = b.empno);
INDEX 보기?
SELECT * FROM USER_INDEXES
--데이터 사전 뷰는 인덱스의 이름과 그것의 유일성을 디스플레이 합니다.
SELECT * FROM USER_IND_COLUMNS
--뷰는 인덱스명,테이블명,열명을 디스플레이 합니다.
SELECT * FROM ALL_OBJECTS where object_type='INDEX';
--현재 계정에 생성된 모든 인덱스 보기(속도느림)
SELECT * FROM USER_OBJECTS WHERE OBJECT_TYPE='INDEX';
--현재 계정에 생성된 모든 인덱스 보기(속도빠름)
--현재 계정에 생성된 모든 인덱스 보기(속도빠름)
select ic.index_name,
ic.column_name,
ix.uniqueness
from user_indexes ix, user_ind_columns ic
where ic.index_name = ix.index_name
and ic.table_name = 'ACCOUNT';
--ACCOUNT TABLE의 인덱스 정보를 검색합니다.
ic.column_name,
ix.uniqueness
from user_indexes ix, user_ind_columns ic
where ic.index_name = ix.index_name
and ic.table_name = 'ACCOUNT';
--ACCOUNT TABLE의 인덱스 정보를 검색합니다.
INDEX 삭제?
사용형식
DROP INDEX INDEX_NAME;
사용예제
DROP INDEX BYC_LOVE_IDX;
※ TABLE이 삭제되면 INDEX도 삭제된다.
※ 인덱스의 소유자와 DROP ANY INDEX권한을 가진 사람만 인덱스 삭제가 가능합니다.
datecolumn => '20060517' and datecolumn <= '20060517' 좌측의 쿼리가 인덱스 안
타는 경우
1. 인덱스키가 아님
2. 복합키 인덱스인데 첫번째 컬럼에 조건을 안준 경우
3. 인덱스 스캔을 했을때 전체 데이터의 10~15% 이상이 되어 옵티마이져가 판단했을때
4. 인덱스 스캔이 불리하다고 판단되어 강제로 인덱스안타는 풀스캔 타는 경우
5. 좌변이 가공되어 인덱스 안탐
자주 쓰이지 않는 통계용 쿼리에는 인덱스를 주지 않는다.
여기서 인덱스를 준다는 얘기는 조건절에 인덱스를 안타는 컬럼에 인덱스를 생성해준다는
얘기이다. 이때는 create temp table as 해서 임시 테이블 만들어 통계 내용을 모두 담은후에
해당 조건컬럼에 인덱스를 만들어 쿼리하는게 좋다.
