Oracle 퍼지 쿼리의 성능을 어떻게 향상시킬 수 있습니까?

1, 양쪽에'%' 가 있는 질의를 사용하면 Oracle 은 인덱스를 전달하지 않으므로 쿼리 효율성이 떨어집니다.

예: lui _ user _ basewhere t.user _ namelike "%cs%" 에서 count (*) 선택 ：

2. 좋아해요 ...'%' 와'% ....' 모두 색인인데 효율성이 떨어집니다.

3. 다음 SQL 을 사용하면 효율성이 10 배 향상되었지만 데이터 양이 적을 때

Select count (*) from lui _ user _ base where rowid in (select rowid from lui _ user _ base t where t.user _;

나는 100w 홉 데이터로 테스트했는데, 효과는 보통이지만 여전히 느리다. 그 이유는 다음과 같습니다.

Lui _ user _ base t where t.user _ namelike'% cs%' 에서 rowid 선택 ？ 이 SQL 은 매우 빠르고 빠르게 실행되지만 lui _ user _ base where rowid in () 에서 select count (*) 를 넣으면 효율성이 매우 느려집니다.

4, select count (*) from lui _ user _ base t where instr (T. user _ name,' cs ')& gt；; 0

이런 조회는 효과적이고 빠르기 때문에 사용하는 것이 좋습니다. 갑골문의 내부 메커니즘에 대해 잘 모르기 때문에 결과를 설명했을 뿐이다.

어떤 사람들은 전체 텍스트 인덱스를 사용한다고 말합니다. 나는 읽었다. 단계는 비교적 번거롭지만 좋은 방법이다. 나중에 사용하기 위해 보관하십시오.

MIT;

끝;

-최적화

가변 작업 번호

시작

DBMS_JOB 입니다. 제출 (:태스크 번호,' CTX _ ddl.optimize _ index ('inx _ custominfo _ addr _ docs',' 전체'') , SYSDATE,' sysdate+1');

제출;

끝;

여기서 첫 번째 작업의 SYSDATE+( 1/24/4) 는 15 분마다 동기화되고 두 번째 작업의 SYSDATE+ 1 을 나타냅니다 구체적인 시간 간격은 응용 프로그램의 필요에 따라 결정할 수 있습니다.

6, 지표 재구성

색인을 재작성하면 원래 색인이 삭제되고 색인을 재작성하는 데 시간이 오래 걸립니다.

색인 재지정 구문은 다음과 같습니다.

X_CUSTOMINFO_ADDR_DOCS 재구성에서 인덱스 변경

일부 온라인 사용자의 경험에 따르면, Oracle 의 인덱스 재구축 속도도 비교적 빠릅니다. 한 사용자가 이렇게 설명합니다.

Oracle 의 전체 텍스트 검색은 ms SQL server 보다 인덱싱 및 유지 관리 속도가 훨씬 빠릅니다. 650,000 개의 레코드가 있는 테이블을 인덱스화하는 데는 20 분, 한 번에 1 분 밖에 걸리지 않습니다.

따라서 작업별로 정기적으로 색인을 재작성하는 것도 고려해 볼 수 있습니다.