쿼리 성능 저하

우리는 처리 해야하는 데이터의 양에 따라 일반적으로 0.5-6.0 초 안에 실행되는 큰 (10,000 + 라인) 절차가 있습니다. 지난 달 동안 FULLSCAN으로 통계 업데이트를 수행 한 후 30 초 이상 걸리기 시작했습니다. 속도가 느려지면 야간 통계 작업이 다시 실행될 때까지 sp_recompile이 문제를 "수정"합니다.

느리고 빠른 실행 계획을 비교하여 특정 테이블 / 인덱스로 좁혔습니다. 느리게 실행될 때 특정 인덱스에서 ~ 300 개의 행이 반환되는 것으로 추정됩니다. 빠르게 실행하면 1 개의 행을 추정합니다. 느리게 실행되면 인덱스에서 검색을 수행 한 후 테이블 스풀을 사용하고 빠르게 실행되면 테이블 스풀을 수행하지 않습니다.

DBSS SHOW_STATISTICS를 사용하여 인덱스 히스토그램을 Excel로 그래프로 표시했습니다. 필자는 일반적으로 그래프가 "롤링 힐스"가 더 많을 것으로 예상하지만 대신 그래프에서 다른 대부분의 값보다 2 배에서 3 배 높은 산인 것처럼 보입니다.

FULLSCAN없이 통계를 업데이트하면 더 정상적인 것처럼 보입니다. 그런 다음 FULLSCAN으로 다시 실행하면 위에서 설명한 것처럼 보입니다.

이것은 매개 변수 스니핑 문제처럼 느껴지며 특히 위의 이상한 인덱스 분포와 관련이 있습니다.

proc가 테이블 값 매개 변수를 가져옵니다. 테이블 값 매개 변수에서 매개 변수 스니핑이 발생할 수 있습니까?

편집 : proc은 12 개의 다른 매개 변수도 사용합니다.이 중 일부는 선택 사항이며 두 가지는 시작 및 종료 날짜입니다.

히스토그램이 이상합니까, 아니면 잘못된 나무를 짖고 있습니까?

쿼리를 조정하거나 인덱싱을 조정하려고 시도하는 것이 편합니다. 그것이 훌륭한 해결책이라면, 그 시점에서 내 질문은 기울어 진 히스토그램에 관한 것입니다.

이것이 PK IDENTITY 클러스터형 인덱스임을 언급해야합니다. 서로 통신하는 두 개의 시스템이 있는데, 하나는 레거시 시스템이고 다른 하나는 새로운 자체 개발 시스템입니다. 두 시스템 모두 유사한 데이터를 저장합니다. 새 시스템에서이 테이블의 PK를 동기화 상태로 유지하기 위해 데이터가 전달되지 않더라도 (예 : RESEED가 완료된 경우에도) 기존 시스템에 항목을 추가 할 때 증가합니다. 따라서이 열의 번호 매기기에 약간의 차이가있을 수 있습니다. 레코드는 거의 삭제되지 않습니다.

어떤 생각이라도 대단히 감사하겠습니다. 더 많은 정보를 수집 / 포함하게되어 기쁩니다.

결국 매개 변수 스니핑과 관련이 있습니다. 통계가 다시 작성된 직후에이 쿼리의 이상한 형태의 일부 버전이 실행되고있는 것입니다. 따라서 캐시 된 계획은 대부분의 통화를 대표하지 않았습니다. 날짜 매개 변수를 로컬 변수에 복사하는 트릭을 사용했으며 성능에는 거의 영향을 미치지 않고 정상적으로 작동합니다. 이것은 히스토그램이 왜 그렇게 "off"로 보이는지에 대한 대답은 아니지만 내 성능 문제를 설명합니다.