데이터베이스 질문과 답변
[질문] 인덱스 생성 시점
0
4
2,338
by 손형선 [2007.10.25 09:25:53]
테이블을 생성하면서 PK 를 만들고 기본데이터를 인써트하는 것과
테이블을 생성하고 기본데이터를 인써트 후에 PK 를 만드는 것이
인덱스 TREE 의 구조가 더 좋아지는 것이 맞는지 궁금합니다.
그리고 최초 인덱스 TREE 가 생성되는 시점은 인덱스가 WHERE 절에 걸린
쿼리가 처음 실행되는 시점이 맞는지요?
그리고, 테이블에 A, B, C , D, E 칼럼이 있고, 주로
select a, b from c 라는 쿼리를 사용한다면 a, b, c를 인덱스로 만들어서
블록 액세스를 없애는게 좋은 방법인지 궁금합니다.
테이블은 update는 없으며 insert는 간혹 발생한다는 전제이며, d,e 칼럼을
select 하는 경우는 매우 드문 경우입니다.
by 손형선
[2007.10.25 00:00:00]
정정. 인덱스는 C+A+B 로 구성되었습니다.
by 장태길
[2007.10.25 00:00:00]
속도 차이가 날듯.. 대량 인서트 시에 인덱스?z 데이타 모두 로딩 후에 따로 작업 하죠.. tree 가 망가진 경우 rebuild 작업을 따로 해야겠죠.
tree 는 사전에 만들어있지 않을까요 ?
대량 작업 후 select 첨 돌리면 첨엔 거의 죽음일것으로 예상되는데 이건말이 안될것 같습니다.
나머진 패스..
tree 는 사전에 만들어있지 않을까요 ?
대량 작업 후 select 첨 돌리면 첨엔 거의 죽음일것으로 예상되는데 이건말이 안될것 같습니다.
나머진 패스..
by 현
[2007.10.25 00:00:00]
약간 논란의 소지가 있는 질문이기는 합니다.
대량의 데이터를 입력하실 때는 태길님 말씀대로 데이터 다 부어 놓으신 후 인덱스작업을 하시면 됩니다. 데이터가 들어갈 때 인덱스도 같이 만들기 때문에 데이터는 병렬로 집어 넣는다 해도 인덱스 만드는데 시간이 많이 걸릴 겁니다.
그러나,
인서트가 간혹 발생한다 하셨는데 그렇다면 굳이 이런 고민을 할 필요가 있는지 의문입니다.
그냥 아무래도 상관은 없습니다.
단지, 인덱스 구성시에는 블록엑세스를 안하기 위해서 c컬럼까지 인덱스를 잡아주시는 것도 방법일 수 있습니다.
이 또한 대용량 테이블일 경우 해당 될 수 있겠구요, 인서트가 간혹 발생하는 작은 테이블의 경우
full스캔을 해도 몇블록에 다 올라오는 경우엔 인덱스 조차도 별 의미가 없어질 수도 있습니다.
대량의 데이터를 입력하실 때는 태길님 말씀대로 데이터 다 부어 놓으신 후 인덱스작업을 하시면 됩니다. 데이터가 들어갈 때 인덱스도 같이 만들기 때문에 데이터는 병렬로 집어 넣는다 해도 인덱스 만드는데 시간이 많이 걸릴 겁니다.
그러나,
인서트가 간혹 발생한다 하셨는데 그렇다면 굳이 이런 고민을 할 필요가 있는지 의문입니다.
그냥 아무래도 상관은 없습니다.
단지, 인덱스 구성시에는 블록엑세스를 안하기 위해서 c컬럼까지 인덱스를 잡아주시는 것도 방법일 수 있습니다.
이 또한 대용량 테이블일 경우 해당 될 수 있겠구요, 인서트가 간혹 발생하는 작은 테이블의 경우
full스캔을 해도 몇블록에 다 올라오는 경우엔 인덱스 조차도 별 의미가 없어질 수도 있습니다.
by finecomp
[2007.10.25 00:00:00]
나머진 패스 여기서 받겠습니다...^^;
인덱스를 효율적으로 scan하려면 WHERE 조건과 인덱스의 첫번째 시작컬럼의 관계가 매우 중요합니다.
select a, b from 테이블명 where c = :in_condition
의 형태의 쿼리라면 최적화 후보 인덱스는
c + a + b ~ 나 c + b + a ~ 로 시작하는 인덱스가 되겠군요.
단, 말씀하신대로 WHERE 조건이 없는 쿼리라면 인덱스는 full scan 해야 하므로 효율성이 떨어지며,
INDEX_FFS 힌트로 인덱스만을 full scan유도하여 table full scan을 안하게 할 수는 있으나,
인덱스에 없는 컬럼을 한개라도 추출할 때는 random access가 많이 발생하여 오히려 성능이 떨어지는 경우라면 table full scan이 좋을 수 있습니다.
위에 예를 들어드린 두 인덱스후보들도 다른 컬럼까지 추출할 때는 마찬가지로 이 인덱스들을 scan한 후 범위를 확 줄여주지 못해 최종 추출할 row수가 매우 많다면 이 또한 random access가 많이 발생하여 full scan이 유리할 수도 있습니다.
즉, 인덱스를 생성할꺼냐 안할꺼냐에 대한 답은 단편적인 한두가지 사실로만 답할 수 있는 경우보다는 보다 많은 전사적/전략적 고민을 한 후 결정할 수 있다는 말입니다...;
건승하시길...수고하세요~~
인덱스를 효율적으로 scan하려면 WHERE 조건과 인덱스의 첫번째 시작컬럼의 관계가 매우 중요합니다.
select a, b from 테이블명 where c = :in_condition
의 형태의 쿼리라면 최적화 후보 인덱스는
c + a + b ~ 나 c + b + a ~ 로 시작하는 인덱스가 되겠군요.
단, 말씀하신대로 WHERE 조건이 없는 쿼리라면 인덱스는 full scan 해야 하므로 효율성이 떨어지며,
INDEX_FFS 힌트로 인덱스만을 full scan유도하여 table full scan을 안하게 할 수는 있으나,
인덱스에 없는 컬럼을 한개라도 추출할 때는 random access가 많이 발생하여 오히려 성능이 떨어지는 경우라면 table full scan이 좋을 수 있습니다.
위에 예를 들어드린 두 인덱스후보들도 다른 컬럼까지 추출할 때는 마찬가지로 이 인덱스들을 scan한 후 범위를 확 줄여주지 못해 최종 추출할 row수가 매우 많다면 이 또한 random access가 많이 발생하여 full scan이 유리할 수도 있습니다.
즉, 인덱스를 생성할꺼냐 안할꺼냐에 대한 답은 단편적인 한두가지 사실로만 답할 수 있는 경우보다는 보다 많은 전사적/전략적 고민을 한 후 결정할 수 있다는 말입니다...;
건승하시길...수고하세요~~
) 버튼을 클릭하여 작성 하시면 됩니다.