SQL 성능 최적화 포 지 셔 닝 네트워크 성능 문제 의 방법(DEMO)

최근 프로젝트 팀 동료 가 나 에 게 SQL 성능 문제 에 부 딪 혔 다 고 말 했다.그 는 전체 표 가 69 개의 기록 만 있 고 클 라 이언 트 의 집행 에 2 분 여 가 걸 려 과학적 이지 않다 고 말 했다.나 는 원인 을 분석 하고 해결 하 는 것 을 도 왔 다.아래 의 작은 편집 은 유사 한 표 구 조 를 설치 하고 사례 를 구 조 했 으 며 테스트 캡 처 는 다음 과 같다.

이 표 는 그림 을 데이터베이스 에 저장 하기 때문에 13800 KB(즉 13M 여 크기)가 있 습 니 다(ItemPhoto 필드 는 iamge 형식)입 니 다.이것 은 역사적 인 원인 입 니 다.잠시 이런 디자인 을 뿌리 지 않 습 니 다.보아하니 이 SQL 의 실행 시간 이 긴 성능 문 제 는 IO 와 SQL 자체 의 실행 계획 에 문제 가 있 는 것 이 아니 라 네트워크 데이터 전송 시간 에 있다(서버 와 클 라 이언 트 는 타지 에 있 고 두 전선 의 대역 폭 은 6M 이지 만 많은 응용,메 일,시스템 은 이 전선 에 의존한다).

sp_spaceused 'Item_Test' name rows reserved data index_size unused----------- ------------- ---------- -------------- ----------- -------------Item_Test 69 13864 KB 13800 KB 16 KB 48 KB 

제 생각 을 검증 하기 위해 서 저 는 서버 본 컴퓨터 에서 테스트 시간 이 2 초 입 니 다.다음 캡 처 와 같 습 니 다.

위 에서 우 리 는 클 라 이언 트 에서 이 SQL 문 구 를 실행 하 는 데 총 2 분 23 초가 걸 렸 다 는 것 을 알 았 다.그러면 클 라 이언 트 는 도대체 몇 바이트 의 데 이 터 를 얻 었 고 데이터 전송 에 얼마나 걸 렸 습 니까?이 DETAIL 정 보 를 볼 수 있 을까요?답 은 돼.SSMS 도구 모음 에서'Include Client Statistics'를 선택 하거나 단축 키 SHIFT+ALT+S 를 사용 한 다음 SQL 문 구 를 실행 하면 다음 과 같은 캡 처 정 보 를 얻 을 수 있 습 니 다.

Client Statistics(클 라 이언 트 통계 정보)는 Query Profile Statistics,Network Statistics,Time Statistics 세 가 지 를 포함한다.
이 부분의 내용 은 이해 하기 쉬 우 니 더 말 할 필요 가 없다.그럼 우리 한번 봅 시다.
Network Statistics(네트워크 통계 정보)Number of server roundtrips:서버 왕복 횟수 TDS packets sent from client:클 라 이언 트 에서 보 낸 TDS 패 킷(개수)TDS packets received from server:서버 에서 받 은 TDS 패 킷(개수)Bytes sent from client:클 라 이언 트 에서 보 낸 바이트 수 Bytes received from server:서버 에서 받 은 TDS 패 킷(개수)Bytes sent from client:클 라 이언 트 에서 보 낸 바이트 수 Bytes received from server:받 은 바이트 수 Time Stattistics:(시간 통계 정보)Client processing time:클 라 이언 트 처리 시간 Total execution time:총 실행 시간 Wait time on server replies:서버 응답 대기 시간
클 라 이언 트 에서 보 낸 바이트 와 서버 에서 받 은 데이터 의 크기 가 뚜렷 하고 명료 하 다.그러면 데 이 터 를 서버 에서 클 라 이언 트 에 게 보 내 는 데 걸 리 는 시간 은 여기에 없다.사실은 클 라 이언 트 처리 시간(Client processing time)에 가깝다.우 리 는 클 라 이언 트 처리 시간 권 을 네트워크 데이터 전송 시간 으로 할 수 있다.상기 사례 에서우 리 는 이 시간 이 140 초(140132 ms)걸 린 것 을 볼 수 있 습 니 다.이 SQL 의 성능 이 데이터베이스(Server Processing Time)보다 느 린 것 이 아니 라 네트워크 데이터 전송 에 느리다 는 것 을 확신 할 수 있 습 니 다.
다음 그림 을 살 펴 보 겠 습 니 다.이것 은 SQL SERVER 의 요청 수신 과 데이터 출력 에 대한 대체적인 흐름 도 입 니 다.클 라 이언 트 가 요청 을 보 낼 때 서버 가 클 라 이언 트 가 보 낸 마지막 TDS 패 키 지 를 받 을 때 데이터베이스 엔진 이 요청 을 처리 하기 시 작 했 습 니 다.요청 이 완료 되면 데 이 터 를 클 라 이언 트 에 게 보 냅 니 다.그림 에서 볼 수 있 습 니 다.클 라 이언 트 가 서버 에서 되 돌아 오 는 데 이 터 를 받 는 데 도 과정 이 필요 합 니 다(또는 시간).

SQL 최적화 과정 에서 만약 에 SQL 에 성능 문제 가 발생 하면 우 리 는 전체적인 측면 에서 문 제 를 분석 해 야 한다.CPU 자원,네트워크 대역 폭,디스크 IO,실행 계획 등 여러 측면 에서 분석 해 야 문제 의 원인 을 분석 하고 포 지 셔 닝 하 는 데 도움 이 될 것 이다.SQL 응답 이 느 릴 때 만 이 아니다.무조건 조건 반사 식 선입견 위주:이것 은 데이터 베이스 문제 이다.데이터베이스 도 늘 이 누명 을 뒤 집어 쓰 면 안 된다.
데이터베이스 대기 이벤트 중,ASYNCNETWORK_IO 는 네트워크 성능 문 제 를 다른 측면 에서 반영 할 수 있다.ASYNC 에 대하 여NETWORK_IO 대기 유형:
This waittype indicates that the SPID is waiting for the client application to fetch the data before the SPID can send more results to the client application.
그러면 이 SQL 을 어떻게 최적화 하 는 지 에 대한 문제 로 돌아 가면 우 리 는 다음 과 같은 몇 가지 측면 에서 최적화 할 수 있다.
1:SQL 은 필요 한 필드 데이터 만 가 져 옵 니 다.
이 사례 처럼 사실 Item 이 필요 없습니다.Photo 필드 데이터,그러면 우 리 는 SQL 을 수정 할 수 있 습 니 다.우리 가 필요 로 하 는 필드 데이터 만 취하 면 이 문 제 를 피 할 수 있 고 SQL 의 성능 을 향상 시 킬 수 있 습 니 다.또한 제 경험 에 따라 개발 자 들 은 SELECT*를 습관 적 으로 사용 합 니 다.그 데이터 가 필요 하 든 필요 하지 않 든 먼저 모두 가 져 온 다음 에 이런 습관 적 인 행 위 는 좋 은 습관 이 아 닙 니 다.
2:이런 뇌 장애 디자인 피하 기
그림 은 응용 서버 에 파일 형식 으로 저장 해 야 한다.데이터 베 이 스 는 경로 정보 만 저장 해 야 한다.이런 그림 을 데이터 베이스 에 저장 하 는 디자인 은 순 전 히 뇌 장애 행위 이다.
위 에서 말 한 것 은 작은 demo 를 통 해 여러분 에 게 소개 한 SQL 성능 최적화 의 포 지 셔 닝 네트워크 성능 문제 의 방법 입 니 다.여러분 에 게 도움 이 되 기 를 바 랍 니 다!