index 파일이란 primary 로 지정하거나 또는 직접 index file을 생성할 경우
key 가 되는 컬럼들에 물리적인 record의 pointer등을 추가한 후 sort하여
저장된 파일입니다
index 파일은 record가 변동(insert,update,delete,alter)시마다 다시 sort가
되야 하므로 CPU 를 많이 사용합니다
그러므로 index가 많으면 많을수록 CPU는 낭비가 됩니다
▶ index 생성시 다음과 같은점에 주의하세요
1.인덱스가 없는 테이블에 데이타를 삽입한 다음 인덱스를 생성하는 것이
유리 - resort(rebuild)를 한번에 시켜야 rebuld time을 절약합니다
2.데이타가 없는 테이블에 인덱스를 만들면 데이타 삽입시마다 인덱스를
갱신하기 때문에 성능의 저하를 가져온다 - 1번과 같은 상황
3.Table의 크기가 작으면 Index를 만들지 않는 것이 좋다 - index 생성의
overhead
4.자주 사용되는 column을 index로 설정하고 갱신 위주의 table은 index가
적은 것이 유리 - rebuild 횟수를 줄입니다
5.인덱스가 많으면 수정시 부하가 많아진다 - 매번 rebuuld를 해야 하므로...
6.읽기 전용인 경우 인덱스 사용이 유용하지만 갱신 위주의 테이블이라면
인덱스가 적은 것이 유리 - 5번과 같은 상황
7.DELETE가 자주 일어나는 테이블은 주기적으로 해당 INDEX를 재생성시켜준다
참고로 Oracle과 같은 RDBMS의 경우는 index의 build/rebuild를 병렬화 하는
기능이 있어서 어느정도의 index overhead를 줄입니다
당연히 여러 프로세스에 의해 인덱스가 생성되므로 단일 서버가 인덱스를
생성할때보다 빠르게 인덱스를 생성하겠죠
또한 주기적으로 생성한 index 의 사용률을 검사하여 계속 index를 사용할지의
여부를 판단하는 것이 좋은데 이것도 Oracle과 같은 RDBMS의 경우에만
인뎃스 모니터링 기능이 지원되므로 Paradox와 같은 xBase 계열은
개발자가 직접 해줘야 합니다
index 파일이란 primary 로 지정하거나 또는 직접 index file을 생성할 경우
key 가 되는 컬럼들에 물리적인 record의 pointer등을 추가한 후 sort하여
저장된 파일입니다
index 파일은 record가 변동(insert,update,delete,alter)시마다 다시 sort가
되야 하므로 CPU 를 많이 사용합니다
그러므로 index가 많으면 많을수록 CPU는 낭비가 됩니다
▶ index 생성시 다음과 같은점에 주의하세요
1.인덱스가 없는 테이블에 데이타를 삽입한 다음 인덱스를 생성하는 것이
유리 - resort(rebuild)를 한번에 시켜야 rebuld time을 절약합니다
2.데이타가 없는 테이블에 인덱스를 만들면 데이타 삽입시마다 인덱스를
갱신하기 때문에 성능의 저하를 가져온다 - 1번과 같은 상황
3.Table의 크기가 작으면 Index를 만들지 않는 것이 좋다 - index 생성의
overhead
4.자주 사용되는 column을 index로 설정하고 갱신 위주의 table은 index가
적은 것이 유리 - rebuild 횟수를 줄입니다
5.인덱스가 많으면 수정시 부하가 많아진다 - 매번 rebuuld를 해야 하므로...
6.읽기 전용인 경우 인덱스 사용이 유용하지만 갱신 위주의 테이블이라면
인덱스가 적은 것이 유리 - 5번과 같은 상황
7.DELETE가 자주 일어나는 테이블은 주기적으로 해당 INDEX를 재생성시켜준다
참고로 Oracle과 같은 RDBMS의 경우는 index의 build/rebuild를 병렬화 하는
기능이 있어서 어느정도의 index overhead를 줄입니다
당연히 여러 프로세스에 의해 인덱스가 생성되므로 단일 서버가 인덱스를
생성할때보다 빠르게 인덱스를 생성하겠죠
또한 주기적으로 생성한 index 의 사용률을 검사하여 계속 index를 사용할지의
여부를 판단하는 것이 좋은데 이것도 Oracle과 같은 RDBMS의 경우에만
인뎃스 모니터링 기능이 지원되므로 Paradox와 같은 xBase 계열은
개발자가 직접 해줘야 합니다