내 프로그램 쿼리 데이터베이스가 느립니다. 어떻게 조회 속도를 높일 수 있습니까?

1. 쿼리를 최적화하려면 가능한 한 전체 테이블 스캔을 피해야 합니다. 먼저 where 와 order by 에 관련된 행에서 색인을 작성하는 것을 고려해야 합니다.

2. where 절의 필드 null 값을 판단하지 않도록 합니다. 그렇지 않으면 엔진은 인덱스 사용을 포기하고 다음과 같이 전체 테이블을 스캔합니다.

T 에서 id 를 선택합니다. 여기서 num 은 비어 있습니다

Num 의 기본값을 0 으로 설정하여 테이블의 num 열에 빈 값이 없도록 한 다음 다음과 같이 질의할 수 있습니다.

T 에서 id 를 선택합니다. 여기서 num=0 입니다

3. where 절에 사용하지 않도록 노력하십시오! = 또는

4. where 절에 or 연결 조건을 사용하지 않도록 합니다. 그렇지 않으면 엔진이 인덱스 사용을 중단하고 전체 테이블을 스캔합니다. 예를 들면 다음과 같습니다.

T 에서 id 를 선택합니다. 여기서 num= 10 또는 num=20 입니다

다음과 같이 질의할 수 있습니다.

Select id from t where num =10

공동 소유

T 에서 id 를 선택합니다. 여기서 num=20 입니다

5.in 과 not in 도 주의해서 사용해야 합니다. 그렇지 않으면 다음과 같은 전체 테이블 스캔이 발생합니다.

Select id from t where num in (1,2,3)

연속 값의 경우 in 대신 between 을 사용할 수 있습니다.

T 에서 id 를 선택합니다. 여기서 num 은 1 에서 3 사이입니다

다음 쿼리로 인해 전체 테이블 스캔도 발생합니다.

T 에서 id 를 선택합니다. 여기서 이름은' %abc%' 입니다

효율성을 높이기 위해 전체 텍스트 검색을 고려해 볼 수 있다.

7. where 절에 매개변수를 사용하면 전체 테이블 스캔도 발생합니다. SQL 은 런타임 시에만 로컬 변수를 구문 분석하므로 최적기는 실행 시간까지 액세스 계획 선택을 연기할 수 없습니다. 컴파일할 때 선택해야 합니다. 그러나 액세스 계획이 컴파일 시 설정된 경우 변수 값은 여전히 알 수 없으므로 인덱스 선택에 대한 입력으로 사용할 수 없습니다. 다음 명령문은 전체 테이블을 스캔합니다.

Select id from t where num=@num

질의에 인덱스를 사용하도록 강제할 수 있습니다.

Select id from t with(index) 여기서 num=@num 입니다.

8. 가능하면 where 절의 필드에 대한 표현식 작업을 피하십시오. 이로 인해 엔진이 인덱스 사용을 포기하고 전체 테이블을 스캔합니다. 예를 들면 다음과 같습니다.

Select id from t 여기서 num/2= 100

다음과 같이 변경해야 합니다.

Select id from t where num =100 * 2

9. 가능하면 where 절의 필드에 대한 함수 작업을 피해야 합니다. 이렇게 하면 엔진이 인덱스 사용을 포기하고 전체 테이블을 스캔합니다. 예를 들면 다음과 같습니다.

Select ID from where substring (name, 1, 3)=' ABC '- ABC 로 시작하는 이름 id.

Select id from where datediff (일, 생성일,' 2005-11-30') = 0-'2005-/

다음과 같이 변경해야 합니다.

T 에서 id 를 선택합니다. 여기서 이름은 "abc%" 입니다

Select id from t where create date > ='2005- 1 1-30' 및 작성 날짜 & lt'2005- 12- 1

10. where 절의 "=" 왼쪽에서 함수, 산술 또는 기타 표현식 연산을 수행하지 마십시오. 그렇지 않으면 시스템에서 인덱스를 제대로 사용하지 못할 수 있습니다.

1 1. 인덱스 필드를 조건으로 사용할 때 인덱스가 복합 인덱스인 경우 시스템에서 인덱스를 사용하도록 인덱스의 첫 번째 필드를 조건으로 사용해야 합니다. 그렇지 않으면 인덱스가 사용되지 않고 필드 순서가 가능한 인덱스 순서와 일치해야 합니다.

12. 무의미한 조회를 쓰지 마라. 빈 테이블 구조를 생성해야 하는 경우 다음을 수행합니다.

선택 col1,col2 into #t from t 여기서 1=0

이 코드는 결과 세트를 반환하지 않지만 시스템 리소스를 사용합니다. 이렇게 바꿔야 합니다.

표 #t (...) 만들기

13. 많은 경우 exists 로 대체하는 것이 좋습니다.

A 에서 번호를 선택합니다. 여기서 번호는 (b 에서 번호 선택) 입니다

다음 문으로 바꿉니다.

Select num from a where exists (select1from b where num = a.num)

14. 모든 색인이 질의에 유효한 것은 아닙니다. SQL 은 테이블의 데이터를 기준으로 조회를 최적화합니다. 인덱스 열에 많은 중복 데이터가 있는 경우 SQL 쿼리에서 인덱스를 사용하지 않을 수 있습니다. 예를 들어, 표에 필드, 남성, 여성의 거의 절반이 있는 경우 색인이 성별에 세워져도 질의 효율성에 영향을 미치지 않습니다.

15. 색인이 많을수록 좋습니다. 색인은 해당 선택의 효율성을 향상시킬 수 있지만 삽입 및 업데이트의 효율도 떨어집니다. 삽입 또는 업데이트 중에 색인이 재작성될 수 있으므로 색인 작성 방법은 상황에 따라 신중하게 고려해야 합니다. 한 테이블의 인덱스 수는 6 개를 넘지 않아야 합니다. 색인이 너무 많은 경우 자주 사용하지 않는 일부 행에 색인을 작성해야 하는지 여부를 고려해야 합니다.

16. 클러스터된 인덱스 데이터 열의 순서가 테이블 레코드의 물리적 저장 순서이므로 클러스터된 인덱스 데이터 열의 갱신을 가능한 한 피해야 합니다. 열 값이 변경되면 전체 테이블 레코드의 순서가 조정되어 상당한 자원이 소모됩니다. 응용 프로그램 시스템에서 클러스터화된 인덱스 데이터 열을 자주 갱신해야 하는 경우 인덱스를 클러스터된 인덱스로 빌드해야 하는지 여부를 고려해야 합니다.

17. 숫자 필드를 사용해 봅니다. 필드에 숫자 정보만 포함된 경우 가능한 한 문자로 설계하지 마십시오. 이렇게 하면 쿼리 및 연결 성능이 저하되고 저장 오버헤드가 증가합니다. 이는 엔진이 쿼리 및 연결을 처리할 때 문자열의 각 문자를 하나씩 비교하지만 number 유형의 경우 한 번만 비교하는 것으로 충분하기 때문입니다.

18. char/nchar 대신 varchar/nvarchar 를 사용합니다. 먼저 긴 필드의 저장 공간이 작아지면 저장 공간이 절약되고, 둘째, 비교적 작은 필드에서 검색하는 것이 쿼리에 훨씬 효율적입니다.

19. 어느 곳에서나 select * from t 를 사용하지 말고' *' 를 특정 필드 목록으로 대체하고 불필요한 필드를 반환하지 마십시오.

20. 가능한 한 중간 테이블 대신 테이블 변수를 사용합니다. 테이블 변수에 많은 양의 데이터가 포함된 경우 인덱스는 매우 제한적입니다 (기본 키 인덱스만 해당).

2 1. 임시 테이블을 자주 생성 및 삭제하지 않도록 하여 시스템 테이블 리소스 소비를 줄입니다.

준비 테이블을 사용할 수 없는 것은 아닙니다. 이를 올바르게 사용하면 큰 테이블이나 공용 테이블의 데이터 세트를 반복적으로 참조해야 하는 경우와 같이 일부 루틴을 보다 효율적으로 사용할 수 있습니다. 그러나 일회성 이벤트의 경우 내보내기 테이블을 사용하는 것이 좋습니다.

23. 준비 테이블을 생성할 때 한 번에 많은 양의 데이터를 삽입하는 경우 create table 대신 select into 를 사용하여 많은 수의 로그를 생성하지 않고 속도를 높일 수 있습니다. 데이터 양이 크지 않은 경우 시스템 테이블의 리소스를 줄이려면 테이블을 만든 다음 삽입해야 합니다.

24. 중간 테이블을 사용하는 경우, 저장 프로시저 끝에서 모든 중간 테이블을 명시적으로 삭제해야 합니다. 먼저 truncate table table 을 삭제한 다음 drop table table 을 사용하여 시스템 테이블을 장기간 잠그지 않도록 합니다.

25. 커서의 효율성이 떨어지므로 가능하면 커서를 사용하지 마십시오. 커서 작업의 데이터가 654.38+0 백만 행을 초과하는 경우 다시 쓰는 것을 고려해야 합니다.

26. 커서 기반 또는 임시 테이블 방법을 사용하기 전에 먼저 세트 기반 방법을 찾아 문제를 해결해야 합니다. 일반적으로 세트 기반 방법이 더 효과적입니다.

27. 중간 테이블과 마찬가지로 커서도 사용할 수 없는 것이 아닙니다. 작은 데이터 세트에 f.a.s.t. _ forward 커서를 사용하는 것이 일반적으로 다른 행별 처리 방법보다 낫습니다. 특히 필요한 데이터를 얻기 위해 여러 테이블을 참조해야 하는 경우 더욱 그렇습니다. 결과 세트에 "합계" 를 포함하는 루틴은 일반적으로 커서를 사용하는 것보다 빠릅니다. 개발 시간이 허용되는 경우 커서 기반 및 컬렉션 기반 방법을 모두 시도하여 어떤 방법이 더 효과적인지 확인할 수 있습니다.

28. 모든 저장된 프로시저와 트리거의 시작 부분에 SET NOCOUNT ON 을 설정하고 끝 부분에 set SET NOCOUNT OFF 를 설정합니다. 저장된 프로시저와 트리거의 각 명령문을 실행한 후에는 클라이언트에 DONE_IN_PROC 메시지를 보낼 필요가 없습니다.

29. 큰 트랜잭션 작업을 피하고 시스템 동시성을 향상시킵니다.

30. 클라이언트에 대량의 데이터가 반환되지 않도록 합니다. 데이터의 양이 너무 많으면 해당 요구 사항이 합리적인지 여부를 고려해야 합니다.

1. 이 필드를' null 허용' 으로 설정하지 마십시오

2, 데이터 테이블 디자인 사양.

데이터베이스에 대한 데이터 작업의 작업을 심층적으로 분석합니다.

4. 가급적 중간 테이블을 사용하지 마십시오.

5. 더 많은 거래 사용

6. 가능하면 커서를 사용하지 마십시오.

7. 교착 상태 방지

8. 읽기 및 쓰기 잠금 사용에 주의하십시오.

9. 큰 데이터 세트를 열지 마십시오.

10. 서버측 커서를 사용하지 마십시오.

1 1. 프로그램을 작성할 때 대형 데이터베이스를 사용합니다.

12. 성별 열에 대한 색인을 작성하지 마십시오.

13, 시간 초과 문제 주의

14, select 사용 안 함 *

15. 일람표에 레코드를 삽입할 때 마스터 테이블에서 Select MAX(ID) 를 실행하지 마십시오.

16. 텍스트 데이터 유형을 사용하지 않도록 합니다.

17, 매개 변수 쿼리 사용

18, Insert 를 사용하여 대량의 데이터를 가져오지 마십시오.

19, 분석 및 조회 학습

20. 참조 무결성 사용

2 1, Where 를 내부 및 왼쪽 연결로 바꿉니다.

SQL 쿼리의 효율성 향상 (요점 및 기술);

힌트 1:

문제 유형: ACCESS 데이터베이스 필드에 일본어 가타카나 또는 기타 알 수 없는 문자가 포함된 경우 질의는 메모리 오버플로를 표시합니다.

해결 방법: 질의문을 수정합니다.

Sql = "select * from tablename where column like"% "& 단어 & amp%' "

대체

Sql="select * from tablename "

Rs.filter = "column like'%"& 단어 & amp%' "

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

프롬프트 2:

질문 유형: Baidu 와 같은 다중 키워드 쿼리를 간단한 방식으로 구현하는 방법 (여러 키워드는 공백이나 다른 기호로 구분).

솔루션:

//질의 문자열을 공백으로 구분합니다

Ck=split (단어, "")

//나누기 수량을 가져옵니다

Sck = 언더하중 (CK)

Sql="select * tablename where "

필드의 조회

I = 0 ~ sck 의 경우

Sql = SQL & amptempjoinword & amp "("& _

열 이미지 & ampck (a) & amp%') "

TempJoinWord = "and"

그리고 나서

두 필드 모두에서 조회

I = 0 ~ sck 의 경우

Sql = SQL & amptempjoinword & amp "("& _

열 이미지 & ampck (a)&'%' 또는' & amp_

Column1like "& Ck (a) & amp%') "

TempJoinWord = "and"

그리고 나서

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

팁 3: 쿼리 효율성을 크게 향상시키는 몇 가지 기술.

1. 가능한 한 or 을 사용하지 마십시오. 이로 인해 전체 테이블 스캔이 발생하고 쿼리 효율성이 크게 저하됩니다.

2. charindex () 의 쿼리 효율성 향상이% like 를 초과하지 않는 것으로 입증되었습니다. charindex () 는 인덱스를 쓸모 없게 만듭니다 (SQLServer 데이터베이스 참조).

3.'%' 와 비슷한 열& 단어&'%' 는 색인을 쓸모 없게 만듭니다.

"& 단어&"% "와 같이 색인을 유효하게 합니다 (앞의% 기호 제거).

(SQLServer 데이터베이스 참조)

4.% "& 단어&"% "및"&; 단어& 쿼리의%' 차이:

예를 들어, 당신의 분야 내용은 연약한 여자입니다.

% "& 단어&"% ":"부상 "또는" 하나 "에 관계없이 모든 문자열이 와일드카드가 됩니다.

"& 단어&"% ":앞의 문자열만 와일드카드입니다. 예를 들어, "상처" 를 검색하면 결과가 없고 "하나" 를 검색해야만 결과가 표시됩니다.

5. 필드 추출은' 필요한 만큼' 원칙을 따르고' 선택 *' 을 피하고' 선택 필드 1, 필드 2, 필드 3 ...' 을 사용합니다. 한 개 이하의 필드를 추출할 때마다 데이터 추출 속도가 그만큼 빨라진다는 사실이 입증되었습니다. 승천의 속도는 네가 버린 필드의 크기에 달려 있다.

6.order by 는 클러스터된 인덱스 열별로 가장 효율적으로 정렬됩니다. Sqlserver 데이터 테이블은 클러스터된 인덱스를 하나만 만들 수 있습니다. 기본값은 보통 ID 이며 다른 필드로 변경할 수 있습니다.

7. 테이블에 적합한 색인을 만들면 질의 속도가 수십 배, 심지어 수백 배나 빨라질 수 있습니다. (SQLServer 데이터베이스 참조)

다음은 색인이 있는 경우와 없는 경우의 질의 효율성 분석입니다.

Sqlserver 인덱스 및 쿼리 효율성 분석

식탁 뉴스

분야

Id: 자동 번호 지정

제목: 문장 제목입니다

작성자: 작성자

내용: 내용

별표: 우선 순위

시간 추가: 시간

기록: 654.38+0 만.

테스트 시스템: P4 2.8/ 1G 메모리 /IDE 하드 드라이브.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

시나리오 1:

기본 키 Id, 기본적으로 클러스터된 인덱스입니다. 클러스터되지 않은 다른 인덱스는 생성되지 않습니다.

Select * from news where title like'%' & 단어&'%' 또는'%' 같은 작성자& 단어&'%' Id 별로 desc 정렬

제목 및 작성자 필드에서 Id 별로 정렬된 모호한 검색을 수행합니다.

질의 시간: 50 초

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

옵션 2:

기본 키 Id, 기본값은 클러스터된 인덱스입니다.

제목, 작성자 및 별표에 대한 클러스터되지 않은 색인을 작성합니다.

Select * from news where title like' "& 단어 & amp%' 또는 작성자가 좋아하는'& 단어&'%' 는 Id 별로 desc 를 정렬합니다

제목 및 작성자 필드에서 Id 별로 정렬된 모호한 검색을 수행합니다.

조회 시간: 2-2.5 초

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

옵션 3:

기본 키 Id, 기본값은 클러스터된 인덱스입니다.

제목, 작성자 및 별표에 대한 클러스터되지 않은 색인을 작성합니다.

Select * from news where title like' "& 단어 & amp%' 또는 작가는'& 단어&'%' 를 좋아한다. 스타 desc 별로 정렬한다

제목 및 작성자 필드의 퍼지 검색 (별표별로 정렬).

질의 시간: 2 초

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

옵션 4:

기본 키 Id, 기본값은 클러스터된 인덱스입니다.

제목, 작성자 및 별표에 대한 클러스터되지 않은 색인을 작성합니다.

Select * from news where title like' "& 단어 & amp%' 또는 저자는' "& 단어 & amp%' 를 좋아한다

제목과 작성자 필드에서 퍼지 검색을 수행하고 정렬하지 않습니다.

조회 시간: 1.8-2 초

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

옵션 5:

기본 키 Id, 기본값은 클러스터된 인덱스입니다.

제목, 작성자 및 별표에 대한 클러스터되지 않은 색인을 작성합니다.

Select * from news where title like' "& 단어 & amp%'

또는

작가가 좋아하는 뉴스 중에서 선택하다. 단어 & amp%'

필드 제목 또는 작성자로부터 검색되며 정렬되지 않습니다.

조회 시간: 1 초

SQL 언어의 쿼리 효율성을 어떻게 향상시킬 수 있습니까?

Q: SQL 언어의 쿼리 효율성을 향상시키는 방법은 무엇입니까?

A: 이것은 처음부터 시작해야합니다.

SQL 은 프로시저 지향 쿼리 언어가 아닌 결과 지향 쿼리 언어이므로 SQL 을 지원하는 대규모 관계형 데이터베이스는 일반적으로 쿼리 비용 기반 최적기를 사용하여 실시간 쿼리에 가장 적합한 실행 전략을 제공합니다. 최적기의 경우 입력은 쿼리 문이고 출력은 실행 정책입니다.

하나의 SQL 질의문에는 여러 가지 실행 정책이 있을 수 있으며, 최적기는 모든 실행 방법 중에서 시간이 가장 적게 걸리는 소위 비용이 가장 낮은 방법을 추정합니다. 모든 최적화는 주로 where 절의 Serach 매개변수를 사용하여 튜닝되는 사용자가 사용하는 질의 문의 where 절을 기준으로 합니다.

검색 매개 변수의 핵심 아이디어는 데이터베이스가 레코드의 데이터를 직접 쿼리하는 대신 테이블의 필드 인덱스를 사용하여 데이터를 쿼리하는 것입니다.

With =,

Emp_id = "1000 1" 또는 급여 > 3000 또는 a = 1 및 c = 7.

다음은 검색 매개 변수가 아닙니다.

Salary = emp_salary 또는 dep_id! = 10 또는 임금 * 12 > = 3000 또는 a= 1 또는 c=7 입니다.

최적기가 더 많은 선택을 할 수 있도록 가능한 중복 검색 매개변수를 제공해야 합니다. 다음 세 가지 방법을 살펴보십시오.

첫 번째 방법:

Select employee.emp_name, department.dep _ name from department, Employeewhere (employee.dep _ id = department.dep _ id) 및 (department.dep _ code = "0/

검색 분석 결과는 다음과 같습니다.

예상 I/O 작업 2 회

기본 키를 사용하여 부서 스캔

Dep_code 가 "0 1" 인 행의 경우

여기에 도착할 것으로 예상됩니다 1 회

직원을 순서대로 스캔하다

여기에 5 번 도착할 것으로 예상됩니다.

두 번째 방법:

Select employee.emp_name, department.dep _ name from department, employee where (employee.dep _ id)

검색 분석 결과는 다음과 같습니다.

예상 I/O 작업 2 회

기본 키를 사용하여 부서 스캔

Dep_code 가 "0 1" 인 행의 경우

여기에 도착할 것으로 예상됩니다 1 회

직원을 순서대로 스캔하다

여기에 5 번 도착할 것으로 예상됩니다.

첫 번째 방법은 두 번째 방법만큼 효과적이지만 첫 번째 방법은 최적기에 더 많은 옵션을 제공하기 때문에 가장 좋습니다.

세 번째 방법:

Select employee.emp_name, department.dep _ name from department, employee where (employee.dep _ id)

이 방법은 색인을 사용할 수 없기 때문에 최악입니다. 즉, 최적화할 수 없습니다 ...

SQL 문을 사용할 때 다음 사항에 유의하십시오.

1. 호환되지 않는 데이터 유형은 사용하지 마십시오. 예를 들어 Float 과 Integer, Char 와 Varchar, Binary 와 Long Binary 는 호환되지 않습니다. 데이터 유형이 호환되지 않으면 최적기가 수행할 수 있는 몇 가지 최적화 작업을 수행하지 못할 수 있습니다. 예를 들면 다음과 같습니다.

Select emp_name form 직원, 여기서 임금 & gt3000;

이 문에서 salary 가 Float 유형인 경우 최적기는 최적화하기 어렵습니다. 3000 은 정수이므로 런타임 시 DBMS 가 변환할 때까지 기다리지 않고 프로그래밍에서 3000.0 을 사용해야 합니다.

2. 가능한 한 표현식을 사용하지 마십시오. 컴파일 시 사용할 수 없으므로 SQL 은 평균 밀도로만 적중할 레코드 수를 예측할 수 있습니다.

3. 검색 매개 변수에 다른 수학 연산자를 사용하지 마십시오. 예를 들면 다음과 같습니다.

Employee where salary *12 > 에서 EMP _ name 선택 3000;

다음과 같이 변경해야 합니다.

직원 where salary & gt250; 에서 EMP _ name 선택

4, 사용을 피하십시오! = 또는

구강 응용

A160,000 데이터시트-문자 메시지 업테이블 TBL _ 문자 메시지 _ 모

구조:

테이블 TBL_SMS_MO 생성

(참조)

SMS_ID 번호,

MO_ID VARCHAR2(50),

Varchar2 이동 (11) ，

Sp 번호 varchar2 (20),

메시지 VARCHAR2( 150),

TRADE_CODE VARCHAR2(20),

LINK_ID VARCHAR2(50),

게이트웨이 식별 번호,

게이트웨이 포트 번호,

MO_TIME 일자 기본 시스템 일자

);

TBL 월일에 인덱스 생성 IDX 월일

PCTFREE 10

INITRANS 2

MAXTRANS 255

저장; 비축

(참조)

초기 1M

다음 1M

MINEXTENTS 1

MAXEXTENTS 무제한

백분율 증가 0

);

TBL 휴대 전화에서 IDX 휴대 전화 인덱스 생성

PCTFREE 10

INITRANS 2

MAXTRANS 255

저장; 비축

(참조)

초기 64K

다음 1M

MINEXTENTS 1

MAXEXTENTS 무제한

백분율 증가 0

);

질문: 다음 SQL 문에 표시된 대로 표에서 휴대폰이 일정 기간 동안 보낸 문자 메시지를 질의합니다.

휴대폰, 메시지, 거래 코드, 시간 선택

TBL 에서 보낸 문자

여기서 MOBILE=' 130XXXXXXXX' 입니다

그리고 종료 날짜 ('2006-04-0 1',' YYYY-MM-DD HH24:MI:SS') 와 종료 날짜 ('2006-04-)

DESC 시간순으로

결과를 반환하는 데 약 10 분이 걸리며 웹 쿼리에는 견딜 수 없습니다.

분석:

PL/SQL Developer 에서 [계획 설명] 단추 (또는 F5 키) 를 눌러 SQL 을 분석한 결과 기본 인덱스가 IDX _ mo _ date 인 것으로 나타났습니다. 문제는 여기에 있을 수 있다. 1600 만 개의 데이터 양에 비해 두가 이동하는 데이터의 양이 적기 때문에 _MO_MOBILE 을 사용하면 데이터를 더 쉽게 잠글 수 있기 때문이다.

최적화는 다음과 같습니다.

SELECT/*+index(TBL _ 문자 메시지 _ 모 IDX _ 모 _ 휴대폰) */휴대폰, 메시지, 거래 코드, 모 _ 시간

TBL 에서 보낸 문자

여기서 MOBILE=' 130XXXXXXXX' 입니다

그리고 종료 날짜 ('2006-04-0 1',' YYYY-MM-DD HH24:MI:SS') 와 종료 날짜 ('2006-04-)

DESC 시간순으로

테스트:

F8 을 눌러 이 SQL 을 실행합니다. 와우 ~ ..... 2.360s, 이것이 차이점입니다.

Blogs.com/shayeblog/archive/2013/07/31/3227244.html