간단명료

NL조인은 인덱스를 이용한 조인이다. 일반적으로 양쪽 테이블 다 인덱스를 사용하지만 OUTER 쪽 테이블은 사이즈가 크지 않다면 인덱스를 이용하지 않을 수 있다. INNER 쪽 테이블은 Table Full Scan 시 한 번으로 그치지 않기 때문에(OUTER에서 읽은 건수만 큼 Table Full Scan 함) 반드시 인덱스를 사용해야 한다. 4.1.1 기본 메커니즘 // for(i=0; i

3.4.1 인덱스 설계가 어려운 이유 인덱스가 많으면 다음과 같은 문제가 발생한다. DML 성능 저하 (-> TPS,Transaction Per Second 저하) 데이터베이스 사이즈 증가 (-> 디스크 공간 낭비) 데이터베이스 관리 및 운영 비용 상승 3.4.2 가장 중요한 두 가지 선택 기준 조건절에 항상 사용하거나, 자주 사용하는 컬럼을 선정한다. '=' 조건으로 자주 조회하는 컬럼을 앞쪽에 둔다. 3.4.3 스캔 효율성 이외의 판단 기준 그 외 고려할 판단 기준 수행 빈도 업무상 중요도 클러스터링 팩터 데이터량 DML 부하(= 기존 인덱스 개수, 초당 DML 발생량, 자주 갱신하는 컬럼 포함 여부 등) 저장 공간 인덱스 관리 비용 이런 다양한 판단 기준에 대한 해석이 서로 다르기 때문에 설계자의 ..

3.3.1 인덱스 탐색 2.1(.2)(https://gyujingyujin.tistory.com/14?category=1262761) 참고 (page173 예시 참고) 3.3.2 인덱스 스캔 효율성 (page180 예시 참고) 3.3.3 액세스 조건과 필터 조건 인덱스 액세스 조건 인덱스 스캔 범위를 결정하는 조건절. 인덱스 수직적 탐색을 통해 스캔 시작점을 결정하는데 영향을 미치고, 인덱스 리프 블록을 스캔하다가 어디서 멈출지 결정한다. 인덱스 필터 조건 테이블로 액세스할지를 결정하는 조건절. 테이블 필터 조건 쿼리 수행 다음 단계로 전달하거나 최종 결과집합에 포할할지를 결정한다. 인덱스를 이용한 테이블 액세스 비용 = 인덱스 수직적 탐색 비용 + 인덱스 수평적 탐색 비용 + 테이블 랜덤 액세스 비용 ..

부분범위 처리를 활용하면 인덱스로 액세스할 대상 레코드가 아무리 많아도 아주 빠른 응답속도를 낼 수 있다. 3.2.1 부분범위 처리 DBMS가 데이터를 모두 읽어 한 번에 전송하지 않고 먼저 읽는 데이터부터 일정량(Array Size) 을 전송하고 멈추기 때문에 레코드가 아무리 많아도 빨리 출력할 수 있다. 데이터를 전송하고 나면 서버 프로세스는 CPU를 OS에 반환하고 대기 큐에서 잠을 잔다. 다음 Fetch Call을 받으면 대기 큐에서 나와 그다음 데이터부터 일정량을 읽어서 전송하고 또다시 잠을 잔다. 이처럼 전체 쿼리 결과집합을 쉼 없이 연속적으로 전송하지 않고 사용자로부터 Fetch Call이 있을 때마다 일정량씩 나누어 전송하는 것을 '부분범위 처리' 라고 한다.

3.1.1 테이블 랜덤 액세스 인덱스 ROWID는 물리적 주소? 논리적 주소? 인덱스 스캔 후 반드시 테이블을 액세스하는데 실행계획에서 'TABLE ACCESS BY INDEX ROWID' 표시 부분이 여기에 해당된다. SQL> from 고객 where 지역 = '서울'; Excution PLan -------------------------------------------------------------------------------------------- 0 SELECT STATEMENT Optimizer=ALL_ROWS 1 0 TABLE ACCESS BY INDEX ROWID OF '고객' (TABLE) 2 1 INDEX RANGE OF '고객_지역_IDX' (INDEX) 인덱스 ROWID는 메모..