Oracle Index 의 세 가지 문제

보고 있 는 ORACLE 튜 토리 얼 은 Oracle Index 의 세 가지 문제 입 니 다.색인 Index )흔히 볼 수 있 는 데이터베이스 대상 입 니 다.설정 이 좋 고 나 쁨,사용 이 적절 한 지,데이터베이스 응용 프로그램 과 Database 에 큰 영향 을 줍 니 다. 의 성능.색인 용법 을 설명 하 는 자료 가 많 지만, DBA 화해시키다 Developer 사람들 도 자주 그것 과 접촉 하지만 필 자 는 아직도 많은 사람들 이 그것 에 대해 오해 하고 있 기 때문에 사용 중의 흔 한 문제 에 대해 세 가지 문 제 를 이야기 하 는 것 을 발견 했다.이 글 의 모든 예제 에 사용 되 는 데이터 베 이 스 는? Oracle 8.1.7 OPS on HP N series ,예 를 들 어 모두 진실 한 데이터 이 고 독 자 는 구체 적 인 데이터 크기 에 주의 할 필요 가 없 으 며 서로 다른 방법 을 사용 한 후에 데이터 의 비교 에 주의해 야 한다.본 논문 에서 말 하 는 것 은 기본적으로 모두 진부 하고 상투적인 것 이지 만 필 자 는 실제 적 인 예 를 통 해 당신 에 게 일의 관건 을 진정 으로 깨 닫 게 하려 고 합 니 다.  첫째,색인 이 항상 최선 의 선택 은 아니다.  하면,만약,만약... 색인 이 있 는 상태 에서 색인 을 사용 하지 않 았 습 니 다.이것 은 Oracle 이 아 닙 니 다. 의 최적화 기 오류 가 발생 했 습 니 다.어떤 경우 에는 Oracle 전체 표 스 캔 을 선택 하 는 것 이 확실 합 니 다(Full Table 색인 검색 대신 스 캔(Index) Scan）。이런 상황 은 보통 다음 과 같다.  　　1. 표 가 statistics 를 하지 않 았 습 니 다. 혹은 statistics 야기시키다 Oracle 잘못 판단 하 다.  　　2. 이 표 가 가지 고 있 는 기록 수 와 데이터 블록 수 에 따라 실제 전체 표 스 캔 은 색인 스 캔 보다 빠르다.  첫 번 째 상황 에서 가장 흔히 볼 수 있 는 예 는 다음 과 같은 sql 입 니 다. 문장:  statistics 이전 에는 전체 표 스 캔 을 사용 하여 6000 여 개의 데이터 블록(하나의 데이터 블록 은 8k)을 읽 어야 합 니 다. statistics 했 어 요. 다음 INDEX (FAST FULL SCAN) ，450 개의 데이터 블록 만 읽 으 면 됩 니 다.하지만,statistics 잘 하지 못 하면 Oracle 로 이 어 질 수도 있다. 색인 을 사용 하지 않 습 니 다.  두 번 째 상황 은 훨씬 복잡 해 야 한다.일반적으로 개념 적 으로 색인 이 표 보다 빠 르 고 어떤 상황 에서 전체 표 스 캔 이 색인 스 캔 보다 빠르다 고 생각 하 는 지 이해 하기 어렵다.이 문 제 를 분명하게 설명 하기 위해 서 는 먼저 Oracle 을 소개 합 니 다. 색인 사용 대가(cost)를 평가 할 때 두 가지 중요 한 데이터:CF(Clustering) factor) 화해시키다 FF(Filtering factor).  　　CF: 이른바 CF, 쉽게 말 하면 하나의 색인 블록 을 읽 을 때마다 몇 개의 데이터 블록 을 읽 어야 하 는 지 에 대응 하 는 것 이다.  　　FF: 이른바 FF, 바로 문장 이 선택 한 결과 집합 은 전체 데이터 양의 백분율 을 차지한다.  대략적인 계산 공식 은 FF 이다. * (CF + 인덱스 블록 개수) ，이로써 하나의 조회 가 색인 을 사용 하면 읽 어야 할 데이터 블록 수 입 니 다.읽 어야 할 데이터 블록 이 많 을 수록 cost 클 수록,Oracle 선택 하지 않 을 수도 있 습 니 다. index. （전체 표 스 캔 에 읽 어야 할 데이터 블록 수 는 이 표 의 실제 데이터 블록 수 와 같 습 니 다)  그 핵심 은 CF 실제 데이터 블록 보다 수량 이 많 을 수 있 습 니 다.CF 색인 에 있 는 데이터 의 배열 방식 의 영향 을 받 아 색인 이 처음 만 들 어 졌 을 때 색인 에 있 는 기록 과 표 에 있 는 기록 은 좋 은 대응 관 계 를 가진다.CF 모두 작다.표 가 대량의 삽입,수정 을 거 친 후에 이런 대응 관 계 는 점점 복잡 해 지고 CF 점점 커지 고 있 습 니 다.이때 필요 하 다 DBA 이 색인 을 다시 만 들 거나 구성 합 니 다.  하면,만약,만약... 문 구 는 이전에 어떤 색인 을 사용 해 왔 는데,비교적 긴 시간 후에 다시 사용 하지 않 을 수도 있다. CF 너무 커 져 서 색인 을 다시 정리 해 야 합 니 다.  　　FF Oracle 근거 statistics 추정예컨대 mytables 표 는 32 만 줄 이 고 메 인 키 my id 의 최소 값 은 1 이 며 최대 값 은 409654 입 니 다.다음 sql 을 고려 하 십시오. 문장:  이 두 마디 는 차이 가 많 지 않 은 것 같다. sql Oracle 하지만 큰 차이 가 있다.전자의 FF 100%입 니 다. 후자 의 FF 이 가능 하 다,~할 수 있다,... 1%。하면,만약,만약... 실제 데이터 블록 보다 크 면 Oracle 완전히 다른 최적화 방식 을 선택 할 수 있 습 니 다.실제로 우리 의 데이터베이스 에서 의 테스트 는 우리 의 예측 을 검증 했다. 다음은 HP 실행 할 때 explain plan:  첫 번 째 문장:  325917 줄 을 선 택 했 습 니 다.  두 번 째 문장:  분명 한 것 은 첫 번 째 문장 은 색인 을 사용 하지 않 았 고,두 번 째 문장 은 메 인 키 색인 pk 를 사용 했다.mytables. FF 의 큰 영향 은 여기 서 엿 볼 수 있다.이로써 우 리 는 sql 을 쓰 고 있다 는 것 을 알 게 되 었 다 말 할 때 미리 예측 해 보면 FF, 너 는 거의 예견 할 수 있다 Oracle 색인 사용 여부. 
[넥 스 트 페이지]2 강,색인 에 도 좋 고 나 쁨 색인 이 있 습 니 다. B tree 색인 Bitmap 색인 Reverse b tree 색인 기다리다가장 많이 쓰 이 는 것 은 B tree 색인 B Balanced , 에서 tree 의 root 어느 leaf ，똑 같이 많이 거 쳐 야 돼 요. level. 색인 은 한 필드 만 있 을 수 있 습 니 다(Single column）, 여러 필드(Composite),최대 32 필드,8I 지지 하 다 Function-based index. 많은 개발 자 모두 일렬 B 를 사용 하 는 경향 이 있다 트 리 인덱스.  색인 의 좋 고 나 쁨 이란:  1.색인 이 많 을 수록 좋 은 것 은 아니다.특히 지금까지 사용 하지 않 았 거나 거의 사용 하지 않 았 던 대량의 색인 은 시스템 에 해 를 끼 칠 뿐이다.OLTP 시스템 은 표 당 5 개의 색인 을 초과 하면 성능 이 떨 어 지고 sql 에 있 습 니 다. 중, Oracle 초과 사용 불가 다섯 개의 색인.  2.단일 색인 이 복합 색인 보다 효율 적 이지 못 한 경우 가 많다.  3.다 중 표 연결 에 사용 되 는 필드 에 색인 을 더 하면 효과 가 있 습 니 다.  그렇다면 어떤 상황 에서 단일 색인 이 복합 색인 보다 효율 적 이지 않 을 까?sql 구문 에서 조회 한 열 은 모두 복합 색인 에 나타 날 때,이 때 는... Oracle 색인 블록 만 조회 하면 모든 데 이 터 를 얻 을 수 있 습 니 다.물론 여러 개의 단일 색인 을 사용 하 는 것 보다 훨씬 빠 릅 니 다.(이때 이런 최적화 방식 은 Index only access path）  그 외 에는?우 리 는 그래도 하나의 예 를 보 자.  ...에 있다 HP（Oracle 8.1.7） 위 에서 다음 문장 을 실행 합 니 다:  처음에 우 리 는 두 개의 단일 색인 이 있 었 다.Imytabs1(coid), I_mytabs2(issuedate), 다음은 실행 상황:  조회 한 것 을 얻 기 위해 7000 개의 데이터 블록 을 읽 은 것 을 볼 수 있다. 6000 여 줄.  현재,이 두 개의 단일 인덱스 를 제거 하고,복합 인덱스 를 추가 합 니 다 Imytabs_test ( coid, issuedate), 다시 실행 합 니 다.결 과 는 다음 과 같 습 니 다.  이번 에는 300 개의 데이터 블록 만 읽 은 것 을 볼 수 있다.  7000 원 대 300 원,이것 이 바로 이 예 에서 단일 색인 과 복합 색인 의 대가 의 비례 이다.이 예 는 우리 에 게 많은 상황 에서 단일 색인 은 복합 색인 보다 효율 적 이지 못 하 다.  색인 설정 문제 에 있어 서 는 할 수 있 는 일이 많다 고 할 수 있다.색인 을 정확하게 설정 하려 면 응용 에 대해 전체적인 분석 을 해 야 한다.  1 3 
[Next Page]제3 강,색인 이 아무리 좋아 도 소 용 없어 요.  앞에서 말 한 것 을 버 리 고 가짜[1]  [2]   다음 페이지보고 있 는 ORACLE 튜 토리 얼 은 Oracle Index 의 세 가지 문제 입 니 다.아주 좋 은 색인 을 설정 하면 모든 바보 들 이 그것 을 사용 해 야 한 다 는 것 을 알 지만 Oracle 하필 이면 쓰 지 않 는 다.그러면 해 야 할 첫 번 째 일 은 너 를 돌아 보 는 것 이다. sql 어구  　　Oracle 색인 을 사용 하려 면 가장 기본 적 인 조건 이 있 습 니 다.  　　1， where 자구 의 이 필드 는 복합 색인 의 첫 번 째 필드 여야 합 니 다.  　　2， where 자구 중의 이 필드 는 어떠한 형식의 계산 에 도 참여 해 서 는 안 된다.  구체 적 으로 말 하면 색인 이 f1, f2, f3 순서 로 만 들 어 졌 습 니 다.지금 하나 있 습 니 다. sql 문구 where 자구 f2 = : var2, ...때문에 f2 색인 의 첫 번 째 필드 가 아니 라 이 색인 을 사용 할 수 없습니다.  두 번 째 문 제 는 우리 사이 에서 매우 심각 하 다.다음은 실제 시스템 에서 잡 은 몇 가지 예:  이상 의 예 는 쉽게 개선 할 수 있다.이러한 문 구 는 매일 우리 시스템 에서 실행 되 며,우리 의 유한 한 cpu 를 소모 합 니 다. 화해시키다 메모리 자원.  1,2 이 두 가 지 를 제외 하고 우 리 는 반드시 마음 에 새 겨 야 할 원칙 외 에 각종 조작 부 대 를 최대한 익 혀 야 한다. Oracle 색인 을 사용 할 지 여부 입 니 다.여기 서 나 는 어떤 조작 이나 조작 부호 만 말 하면 명시 적 으로 막 을 수 있 습 니까? Oracle 색인 사용.다음은 몇 가지 기본 규칙 이다.  　　1， 하면,만약,만약... f1 화해시키다 f2 같은 표 의 두 필드 입 니 다. f1>f2, f1>=f2, f1  　　2， f1 is null, f1 is not null, f1 not in, f1 !=, f1 like ‘%pattern%';  　　3， Not exist  　　4， 어떤 경우 in 색인 도 사용 하지 않 습 니 다.  이런 조작 에 대해 서 는 다른 방법 이 없 으 니 가능 한 한 피 할 수 밖 에 없다.하면,만약,만약... sql 적중 하 다 in 색인 을 사용 하지 않 았 습 니 다.아마도 in 조작 비교 조작 + union all。필 자 는 실천 에서 이것 이 매우 효과 적 이라는 것 을 발견 했다.  하지만 오 라 클 색인 을 진정 으로 사용 하 는 지,색인 을 사용 하 는 것 이 진정 으로 효과 가 있 는 지,아니면 현장 테스트 를 해 야 합 니 다.합 리 적 인 방법 은 쓴 것 이 복잡 하 다 는 것 이다. sql, 응용 프로그램 에 쓰기 전에 제품 데이터베이스 에 explain 을 한 번 합 니 다. . explain Oracle 을 획득 하 게 됩 니 다. 마땅 하 다 sql 명확 하 게 볼 수 있다 Oracle 어떻게 sql 라 고 적 었 다.  하면,만약,만약... explain, 복잡 한 것 을 즐겨 쓴다 는 것 을 알 게 될 것 이다. sql 너무 복잡 한 sql 때문에 좋 은 습관 이 아 닙 니 다. 그 해석 계획 은 종종 만 족 스 럽 지 못 하 다.사실 복잡 하 게 sql 뜯 으 면 효율 을 크게 높 일 수 있다.왜냐하면 좋 은 최 적 화 를 얻 을 수 있 기 때문이다.물론 이것 은 이미 별말 이다. 
 이전 페이지     
이전 페이지    [1]  [2]