SQL Server 병행 작업 최적화 병행 작업 이 억제 되 어 SQL 의 실행 효율 에 영향 을 주지 않도록 합 니 다.

왜 나 도 SQL Server 의 병행 을 말 해 야 합 니까?
요 며칠 동안 정원 에 SQL Server 병행 에 관 한 글 이 많아 서 어쨌든 병행 작업 에 대해 더욱 깊 은 인식 을 가지 게 되 었 다.
내 가 말 하고 싶 은 것 은 병행 작업 이 이런 저런 문제 가 있 을 수 있 음 에 도 불구 하고 우 리 는 병행 을 부인 할 수 없고 병행 을 잘 이용 해 야 한 다 는 것 이다.
그러나 실제 개발 에서 일부 SQL 문장의 쓰기 방법 은 병행 되 지 않 아 SQL 의 집행 효율 에 영향 을 줄 수 있다.
따라서 본 고 에서 표현 하고 자 하 는 것 은 우리 가 병행 을 잘 이용 해 야 한 다 는 것 이다.SQL 의 쓰기 문 제 를'억제'하고 병행 하지 않도록 해 야 한다.우 리 는 병행 이 가 져 온 쾌감 을 누 릴 수 없다.
SQL Server 의 병렬:
병렬 이란 SQL Server 가 실행 대가 가 상대 적 으로 큰(이것 은 당신 의 설정 과 관련 이 있 습 니 다)SQL 을 수행 할 때 데이터베이스 서버 에 여러 개의 CPU 가 존재 하면 SQL Server 조회 엔진 은 병렬 방식 을 사용 합 니 다.즉,여러 개의 CPU 를 사용 하여 전체 연산 과정 에 참여 하고 모든 CPU 는 일부 계산 임 무 를 분담 합 니 다.마지막 으로 각 CPU 의 계산 을 통합 하 는 행 위 는 때때로 부당 한 병행 조회 가 조회 의 속 도 를 가속 화하 지 않 을 뿐만 아니 라 오히려 조회 의 효율 을 늦 출 수 있다.만약 에 부당 한 병행 조작 을 사용 하면 전체 서버 의 안정성 에 영향 을 줄 수 있다.
그래서 SQL Server 가 얼마나 큰 대가 로 병행 을 사용 하 는 지 는 설정 에 의 해 이 루어 집 니 다.이 설정 은 구체 적 인 상황 에 따라 수정 할 수 있 습 니 다.어떤 사람 은 이 값 의 단 위 를'초'라 고 말 합 니 다.권위 있 는 자 료 를 본 적 이 없 는 것 같 습 니 다.도대체 단위 가 무엇 인지 여 기 는 추궁 하지 않 습 니 다.
이 한도 값 단 위 를 잘 아 는 원 우정 은 가르침 을 아 끼 지 않 습 니 다.감사합니다.

비록 병행 작업 은 이렇게 사 는 것 과 같은 문제 가 존재 할 수 있 지만 우 리 는 목이 메 어 폐 식 해 서 는 안 되 고 병행 을 잘 이용 하면 항상 득 보다 실 이 많다.
그러나 모든 실행 대가 가 비교적 큰 SQL 이 병행 작업 을 할 수 있 는 것 은 아니다.실제 개발 에서 일부 SQL 의 쓰 기 는 병행 작업 을 억제 하고 그 결과 전체 SQL 문장(저장 과정)의 효율 을 떨 어 뜨 린 다.
다음은 예 를 들 어 설명 하 겠 습 니 다.
병렬 조회 가 어떻게 직렬 로 바 뀌 었 는 지:
다음은 매우 간단 한 조회 작업 입 니 다.이 쓰기 방법 들 은 기본 적 인 상황 에서 병행 을 열 었 습 니 다.모두 8 개의 스 레 드 를 열 어 SQL 문 구 를 계산 하 는 것 을 볼 수 있 습 니 다.

물론 이 SQL 의 실행 효율 은 괜 찮 은 편 입 니 다.CPU 시간 은 622 밀리초 이 고 실행 총 시간 은 130 밀리초 입 니 다.
여기 서 헷 갈 리 지 마 세 요.CPU 시간의 633 밀리초 는 8 개의 CPU 가 모두 소모 하 는 CPU 시간 입 니 다.전체 실행 130 밀리초 보다 크 면 정상 입 니 다.
아주 간단 한 함 수 를 만 듭 니 다.

CREATE function [dbo].[fn_justFunction](@p_date date)
returns date
as
begin
return @p_date
end

이 함 수 는 실제 적 인 의미 가 없고 실행 도 매우 간단 합 니 다.한 시간 을 입력 하고 이 시간 을 되 돌려 줍 니 다.
물론 여 기 는 아래 의 조작 시연 을 위해 서 입 니 다.당신 은 내 가 알 이 아프다 고 말 할 수 있 습 니 다.나 는 단지 병행 이 억제 되 는 현상 을 보 여주 기 위해 서 입 니 다.
SQL 코드 를 뒤 져 보 세 요.이런 문법 이 있 습 니까?
그리고 우리 가 이 조 회 를 이렇게 쓰 는 것 은 바로 조회 조건 에서 Create Date>dbo.fn 를 이렇게 처리 하 는 것 입 니 다.justFunction('2015-1-1')(표 의 열 이 아니 라 함수 가 조회 조건 에 작용 하 는 것 을 주의 하 세 요)이 함 수 는 어떠한 조회 결과 에 도 영향 을 주지 않 습 니 다.들 어 오 는 2015-1-1 입 니 다.반환 위 치 는 2015-1-1 입 니 다.그러나 이렇게 변화 하면 병행 은 직렬 로 변 합 니 다.SQL 실행 기간 에 하나의 CPU 만 사용 되 었 습 니 다.80%정도 사 용 했 습 니 다.이와 동시에 다른 CPU 는 아무 일 도 없 는 사람과 마찬가지 로 도와 주지 않 습 니까?아니면 한가 합 니까?위의 병행 작업 방식 의 실행 시간 이 얼마 인지 기억 하 십 니까?130 밀리초,지금 굵기 가 얼마나 되 는 지,여 기 는 4S,즉 4000 밀리초 입 니 다.몇 배 차이 가 나 는 지 나 는 수학 을 잘 못 해서 계산 해 낼 수 없다.
이 를 통 해 알 수 있 듯 이 병렬 조작 과 직렬 작업 의 효율 차이 가 매우 크 고 CPU 에 대한 이용 도 충분 하지 않다(물론 모든 CPU 를 꽉 채 워 야 합 리 적 이 라 고 강조 하 는 것 은 아니다)
다시 한 번 강조 하 자 면,여 기 는 표 의 필드 에 함 수 를 더 해서 색인 을 억제 하 는 것 이 아니 라,순수한 영향 은 병행 작업 이다.
물론 병행 을 억제 하 는 문법 은 검색 조건 에서 만 함 수 를 사용 하 는 것 이 아니 라 실제 개발 에서 영향 이 더욱 크다.
실제 업무 에서 데이터 가 더 클 수 있 고 SQL 도 더 복잡 할 수 있 기 때문에 이런 상황 은 더욱 선별 하기 어 려 울 수 있다.
예 를 들 어 연결 조건 에서 다음 과 같이 연결 조건 에서 함 수 를 사용 하여 병행 할 수 없 는 상황 도 실제 개발 에서 만난 것 이다.

select * from TableA a inner join TableB b on a.id=b.id and a.Column=dbo.function(@Variable) where ***

물론 병행 작업 을 억제 하 는 것 은 이 두 가지 쓰기 만 있 는 것 이 아니 라 다른 유사 한 쓰기 도 병행 조회 에 영향 을 미 칠 수 있다.
이것 은 우리 가 SQL 을 쓸 때,더 이상 필드 에서 함 수 를 사용 할 수 없 음 을 주의해 야 할 뿐만 아니 라,검색 조건 에서 도 가능 한 한 함 수 를 사용 하지 마 십시오.병행 작업 에 영향 을 줄 수 있 습 니 다.
병렬 작업 이 억 제 된 경우:
이런 문제 들 을 해결 하려 면 어떻게 해 야 합 니까?사실 매우 간단 합 니 다.조회 조건 은 함수 연산 을 통 해 변 수 를 부여 하고 변 수 를 조회 조건 으로 조회 하 는 것 을 권장 합 니 다.
다시 한 번 즐 거 운 병행 을 시작 해 병행 이 주 는 쾌감 을 즐 겼 다.
연결 조건 의 함수 처리 도 유사 합 니 다.결 과 를 계산 한 후에 하나의 변수 에 저장 하고 변 수 를 연결 조건 에 씁 니 다.
물론 다른 방법 이 있 을 수 있 지만,나 는 아직 생각 하지 못 했다.
요약:
본 고 는 간단 한 예 를 통 해 병행 작업 이 억제 되 는 현상 을 보 여 주 었 고 병행 과 직렬 이 대가 가 큰 SQL 을 수행 하 는 데 있어 서 의 성능 의 큰 차 이 를 설명 했다.
그 중에서 언급 한 조회 방식 은 조회 조건 에서 함수 의 원인 으로 병행 을 억제 하고 조회 열 에서 함 수 를 사용 하여 색인 을 억제 하 는 상황 과 완전히 구별 된다.
병행 조 회 는 CPU 자원 을 충분히 동원 하여 효율 적 인 방식 으로 조 회 를 완성 할 수 있 고 합 리 적 인 병행 을 이용 하면 SQL 의 집행 효율 을 어느 정도 향상 시 킬 수 있다.
병행 을 잘 이용 하기 위해 서 는 SQL 을 쓸 때 병행 작업 이 억제 되 어 성능 에 영향 을 미 치지 않도록 주의해 야 한다.
SQL 최 적 화 는 어렵 고 반복 되 는 과정 이다.그래도 즐겁다.
복잡 한 SQL 에 직면 하여 탄탄 한 기술 뿐만 아니 라 충분 한 인내심 도 가 져 야 사물 의 본질 을 똑똑히 볼 수 있다.
병행 에 대한 이해 가 충분 하지 않 습 니 다.잘못된 점 이 있 습 니 다.여러분 의 지적 에 감 사 드 립 니 다.
위 에서 말 한 것 은 소 편 이 소개 한 SQL Server 병행 작업 최적화 로 병행 작업 이 억제 되 어 SQL 의 집행 효율 에 영향 을 주지 않도록 하 는 것 입 니 다.여러분 께 도움 이 되 기 를 바 랍 니 다.궁금 한 점 이 있 으 시 면 메 시 지 를 남 겨 주세요.소 편 은 신속하게 답 해 드 리 겠 습 니 다.여기 서도 저희 사이트 에 대한 여러분 의 지지 에 감 사 드 립 니 다!