데이터베이스 조회 최적화 기술 실례
16325 단어 검색 최적화
---- ， SQL ， １ （< 1 ）。 ---- ------ ：HP LH II---- ：330MHZ---- ：128 ---- ：Operserver5.0.4---- ：Sybase11.0.3 1. 불합리한 색인 디자인 - 예: 표 record 는 620000 줄 이 있 습 니 다. 서로 다른 색인 에서 다음 SQL 의 운행 상황 을 보 세 요. - 1. date 에 비 군집 색인 을 만 듭 니 다.
select count(*) from record where date >;'19991201' and date < '19991214'and amount >;2000 (25 )select date,sum(amount) from record group by date(55 )select count(*) from record where date >;'19990901' and place in ('BJ','SH') (27 ) - 분석: - date 에는 대량의 중복 값 이 있 습 니 다. 비 군집 색인 에서 데 이 터 는 물리 적 으로 데이터 페이지 에 무 작위 로 저장 되 고 범위 에서 찾 을 때 표 스 캔 을 한 번 실행 해 야 이 범위 안의 모든 줄 을 찾 을 수 있 습 니 다.
날짜 에 있 는 군집 색인
select count(*) from record where date >;'19991201' and date < '19991214' and amount >;2000 （14 ）select date,sum(amount) from record group by date（28 ）select count(*) from record where date >;'19990901' and place in ('BJ','SH')（14 ） - 분석: - 클 러 스 터 색인 에서 데 이 터 는 물리 적 으로 데이터 페이지 에 순서대로 배열 되 고 중복 값 도 함께 배열 되 어 있 기 때문에 범위 에서 찾 을 때 이 범위 의 시작 점 을 먼저 찾 을 수 있 고 이 범위 에서 만 데이터 페이지 를 스 캔 하여 넓 은 범위 의 스 캔 을 피하 고 조회 속 도 를 높 일 수 있다.
- 3. place, date, amount 의 조합 색인
select count(*) from record where date >;'19991201' and date < '19991214' and amount >;2000 （26 ）select date,sum(amount) from record group by date（27 ）select count(*) from record where date >;'19990901' and place in ('BJ, 'SH')（< 1 ） - 분석: - 이것 은 매우 합 리 적 이지 않 은 조합 색인 입 니 다. 선도 열 은 place 이 고 첫 번 째 와 두 번 째 SQL 은 place 를 인용 하지 않 았 기 때문에 색인 을 이용 하지 않 았 습 니 다.세 번 째 SQL 은 place 를 사 용 했 고 인 용 된 모든 열 은 조합 색인 에 포함 되 어 색인 커버 가 되 어 있 기 때문에 속도 가 매우 빠르다.
날짜, place, amount 의 조합 색인
select count(*) from record where date >;'19991201' and date < '19991214' and amount >;2000(< 1 )select date,sum(amount) from record group by date（11 ）select count(*) from record where date >;'19990901' and place in ('BJ','SH')（< 1 ） - 분석: - 이것 은 합 리 적 인 조합 색인 이다.이 는 date 를 선도 열 로 하여 모든 SQL 이 색인 을 이용 할 수 있 도록 하고 첫 번 째 와 세 번 째 SQL 에서 색인 커버 를 형성 하여 성능 이 가장 좋 습 니 다.
--- 5. 총괄:
- 결 성 된 상황 에서 만들어 진 색인 은 비 군집 색인 이지 만 때로는 가장 좋 은 것 이 아니다.합 리 적 인 색인 디자인 은 각종 조회 에 대한 분석 과 예측 에 세 워 야 한다.일반적으로 말 하면:
- ①. 중복 값 이 많 고 범위 조회 가 많다.
(between, >;, <, >; =, < =) 와 orderby, group by 에서 발생 하 는 열 은 클 러 스 터 색인 을 만 드 는 것 을 고려 할 수 있 습 니 다.
- ②. 여러 열 을 동시에 액세스 하고 열 마다 중복 값 을 포함 하여 조합 색인 을 만 드 는 것 을 고려 할 수 있 습 니 다.
- ③. 조합 색인 은 가능 한 한 관건 적 인 조 회 를 색인 으로 덮어 쓰 고 선도 열 은 가장 빈번 한 열 을 사용 해 야 한다.
2. 충전 되 지 않 은 연결 조건: - 예: 표 카드 는 7896 줄 이 고 카드 에 있 습 니 다.no 에 비 집합 색인 이 있 습 니 다. 표 account 는 191122 줄 이 고 account 에 있 습 니 다.no 위 에 비 집합 색인 이 있 습 니 다. 서로 다른 표 연결 조건 에서 두 SQL 의 실행 상황 을 보십시오.
select sum(a.amount) from account a,card b where a.card_no = b.card_no（20 ） ---- SQL ：select sum(a.amount) from account a,card b where a.card_no = b.card_no and a.account_no=b.account_no（< 1 ） - 분석: - 첫 번 째 연결 조건 에서 가장 좋 은 조회 방안 은 account 를 외층 표 로 하고 card 를 내층 표 로 하 며 card 의 색인 을 이용 하여 그 I / O 횟수 는 다음 과 같은 공식 으로 추산 할 수 있다.
- 외층 표 account 의 22541 쪽 + (외층 표 account 의 191122 줄 * 내층 표 card 에서 외층 표 첫 줄 에서 찾 아야 할 3 페이지) = 595907 회 I / O
- 두 번 째 연결 조건 에서 가장 좋 은 조회 방안 은 카드 를 외층 표 로 하고 account 를 내층 표 로 하 며 account 의 색인 을 이용 하여 I / O 횟수 는 다음 과 같은 공식 으로 추산 할 수 있다.
- 외층 표 카드 의 1944 쪽 + (외층 표 카드 의 7896 줄 * 내층 표 account 에서 외층 표 각 줄 에서 찾 아야 할 4 페이지) = 33528 회 I / O
- 이 를 통 해 알 수 있 듯 이 충분 한 연결 조건 만 있어 야 진정한 최선 의 방안 이 실 행 될 수 있다.
- - 총괄:
- 1. 다 중 표 작업 이 실제 실행 되 기 전에 최적화 기 를 조회 하면 연결 조건 에 따라 몇 개의 가능 한 연결 방안 을 열거 하고 그 중에서 시스템 비용 이 가장 적은 가장 좋 은 방안 을 찾아낸다.연결 조건 은 색인 이 있 는 표, 줄 이 많은 표를 충분히 고려 해 야 합 니 다.내외 표 의 선택 은 공식: 외층 표 의 일치 행 수 * 내층 표 에서 매번 찾 는 횟수 를 확정 하고 곱셈 을 최소 화 하 는 것 이 가장 좋 은 방안 입 니 다.
- 2. 실행 방안 을 보 는 방법 - set showplanon 으로 showplan 옵션 을 열 면 연결 순서, 어떤 색인 을 사용 하 는 지 볼 수 있 습 니 다.더 자세 한 정 보 를 보 려 면 sa 캐릭터 로 dbcc (3604, 310, 302) 를 실행 해 야 합 니 다.
3. 최적화 할 수 없 는 where 자구 - 1. 예: 다음 SQL 조건문 의 열 은 모두 적당 한 색인 을 만 들 었 으 나 실행 속 도 는 매우 느리다.
select * from record wheresubstring(card_no,1,4)='5378'(13 )select * from record whereamount/30< 1000（11 ）select * from record whereconvert(char(10),date,112)='19991201'（10 ） - 분석: - where 자구 에서 열 에 대한 모든 조작 결 과 는 SQL 이 실 행 될 때 열 별로 계산 되 기 때문에 표 검색 을 해 야 하 며 이 열 위의 색인 을 사용 하지 않 습 니 다.이 결 과 를 검색 컴 파일 할 때 얻 을 수 있다 면 SQL 최적화 기 에 의 해 최적화 되 고 색인 을 사용 하여 표 검색 을 피 할 수 있 으 므 로 SQL 을 다음 과 같이 다시 쓸 수 있 습 니 다.
select * from record where card_no like'5378%'（< 1 ）select * from record where amount< 1000*30（< 1 ）select * from record where date= '1999/12/01'（< 1 ） --- SQL 이 눈 에 띄 게 빨리 일어 나 는 것 을 발견 할 수 있 을 것 이다!
- 2. 예: 표 stuff 는 20000 줄, idno 에 비 군집 색인 이 있 습 니 다. 아래 SQL 을 보십시오.
select count(*) from stuff where id_no in ('0', '1') (23 초)
- 분석: - where 조건 중의 'in' 은 논리 적 으로 'or' 에 해당 하기 때문에 문법 분석 기 는 in ('0', '1') 을 id 로 전환한다.no ='0' or id_no = '1' 로 실행 합 니 다.우 리 는 그것 이 모든 or 자구 에 따라 각각 찾 고 결 과 를 더 해서 id 를 이용 할 수 있 기 를 기대한다.no 의 색인;그러나 실제 (쇼 플랜 에 따 르 면) "OR 정책" 을 사용 합 니 다. 즉, 모든 or 자 구 를 만족 시 키 는 줄 을 먼저 꺼 내 임시 데이터 베 이 스 를 저장 하 는 워 크 시트 에 저장 한 다음 에 유일한 색인 을 만들어 중복 줄 을 제거 하고 마지막 으로 이 임시 표 에서 결 과 를 계산 합 니 다.따라서 실제 과정 은 id 를 이용 하지 않 았 습 니 다.no 에서 색인 을 올 리 고 완성 시간 은 tempdb 데이터베이스 성능 에 영향 을 받 아야 합 니 다.
- 실천 증명, 표 의 줄 수가 많 을 수록 워 크 시트 의 성능 이 떨 어 집 니 다. stuff 가 620000 줄 이 있 을 때 실행 시간 은 220 초 에 달 합 니 다!차라리 or 자 구 를 나 누 는 것 이 낫다.
select count(*) from stuff where id_no='0'select count(*) from stuff where id_no='1' --- 두 가지 결 과 를 얻 고 한 번 더 덧셈 을 한다.문장 마다 색인 을 사 용 했 기 때문에 실행 시간 은 3 초, 620000 줄 에서 도 시간 은 4 초 에 불과 하 다.또는 더 좋 은 방법 으로 간단 한 저장 과정 을 작성 합 니 다.
create proc count_stuff asdeclare @a intdeclare @b intdeclare @c intdeclare @d char(10)beginselect @a=count(*) from stuff where id_no='0'select @b=count(*) from stuff where id_no='1'endselect @c=@a+@bselect @d=convert(char(10),@c)print @d - 결 과 를 직접 계산 하고 실행 시간 이 위 와 같이 빠르다! -요약:
- 이 를 통 해 알 수 있 듯 이 이른바 최적화 즉 where 자구 가 색인 을 이용 하여 최적화 할 수 없 으 면 표 스 캔 이나 추가 비용 이 발생 한다.
- 1. 열 에 대한 모든 작업 은 표 스 캔 을 가 져 올 것 입 니 다. 데이터베이스 함수, 계산 식 등 을 포함 하고 조회 할 때 가능 한 한 등호 오른쪽 으로 작업 을 옮 겨 야 합 니 다.
- 2. in, or 자 구 는 항상 워 크 시트 를 사용 하여 색인 을 무효 화 합 니 다.만약 대량의 중복 값 이 발생 하지 않 는 다 면 자 구 를 뜯 는 것 을 고려 할 수 있다.뜯 은 자구 에는 색인 이 포함 되 어 있어 야 합 니 다.
- 3. 저장 과정 을 잘 사용 하여 SQL 을 더욱 유연 하고 효율 적 으로 만들어 야 한다.
- 상기 사례 를 통 해 알 수 있 듯 이 SQL 최적화 의 실질 은 결과 가 정확 한 전제 에서 유 틸 리 티 로 식별 할 수 있 는 문 구 를 사용 하고 색인 을 충분히 이용 하여 표 스 캔 의 I / O 횟수 를 줄 이 며 표 검색 의 발생 을 최대한 피 하 는 것 이다.사실 SQL 의 성능 최 적 화 는 복잡 한 과정 이다. 상술 한 것 은 응용 차원 의 일종 의 구현 일 뿐 데이터베이스 층 의 자원 배치, 네트워크 층 의 데이터 제어 와 운영 체제 층 의 총체적인 디자인 도 깊이 연구 할 수 있다.
좋은 웹페이지 즐겨찾기
