내 인덱스를 찾는 것이 올바른 행 수를 추정 할 수 있는데 정렬 연산자가 할 수없는 이유는 무엇입니까?

조건 자에서 함수를 사용하는 쿼리는 다음과 같습니다.

commentType = 'EL'
AND commentDateTime >= DATEADD(month,datediff(month,0,getdate()) - 13,0)

40K 행이있는 commentType에 필터링 된 인덱스가 있으며 쿼리를 실행할 때 인덱스 검색의 예상 행 수는 매우 정확하지만 (약 11K) 다음 단계 (정렬 연산자)의 경우 통계를 완전히 무시하고 필터링 된 인덱스의 총 행 수를 추정합니다.

왜 이런 일이 발생합니까? sargability 에 대한 기본 사항을 알고 있으며 dateadd를 실제 날짜 (2014-01-01) 및 voila로 대체하여 온전함을 위해 테스트했습니다 ... 정렬은 행 수를 올바르게 추측하기 시작했습니다 ...

왜 이런 일이 발생하며 어떻게 해결할 수 있습니까? 고정 날짜를 전달할 수 없습니다 ...

두 개의 DATEDIFF 인수를 바꾸는 추정기 버그로 인해 추정치가 잘못되었다고 생각합니다. 나는 이것에 대해 여기에서 이야기합니다 :

• 성능 놀라움과 가정 : DATEDIFF

해결 방법은 DATEDIFF (2008+)를 사용하지 않고 13 개월 전의 첫 날을 계산하는 것입니다.

DATEADD(MONTH, -13, DATEADD(DAY, 1-DATEPART(DAY,GETDATE()), CONVERT(DATE, GETDATE()));

나는 견적을 처리 할 긍정적 이지 않다 (필터링 된 인덱스로 테스트하지 않았으며, 실제로 정렬이 무엇을하는지 또는 왜 계획 및 / 또는 나머지 쿼리없이 다른 견적이 있는지 확실하지 않습니다. ).

Microsoft가 권장하는 수정 사항은 TF 4199를 사용하는 것이지만 여기서해야 할 것이 확실하지 않습니다.

• 연결 # 630583 :> datediff를 포함하는 조건으로 잘못된 추정

또 다른 옵션은 사용중인 모든 SQL Server 버전에 대해 절대 최신 SP / CU를 사용하고 있는지 확인하는 것입니다. 다음 KB 기사에서 수정되었으므로 여전히 TF 4199를 사용해야합니다. 2014 이상인 경우를 제외하고) :

• KB # 2481274 : FIX : DATEDIFF 함수를 사용하는 쿼리가 SQL Server 2005 또는 SQL Server 2008 또는 SQL Server 2008 R2에서 느리게 실행될 수있다

수정 사항은 다음 빌드로 얻을 수 있습니다.

• 2005 SP3 CU 15 (> = 9.00.4325 및 <= 9.00.4999)
• 2005 SP4 CU 2 (> = 9.00.5259)
• 2008 SP1 CU 13 (> = 10.00.2816.00 및 <= 10.00.3999)
• 2008 SP2 CU 3 (> = 10.00.4279.00 및 <= 10.00.5499)
• 2008 SP3 및 SP4 확장 (> = 10.00.5500)
• 2008 R2 CU 7 (10.50.1777.0)
• 2008 R2 SP1 CU 3 (> = 10.50.2769.0 및 <= 10.50.3999)
• 확장 2008 R2 SP2 및 SP3 (> = 10.50.4000)
• 확장으로 2012, 2014, 2016 (> = 11.0)

(다음에는 SELECT @@VERSION질문에 결과를 포함 시키 십시오.)

KB 기사에 따르면 DATEDIFF는 행 수를 과소 평가할 수 있으며 이는 시나리오에서 발생하는 것과 반대입니다. 그렇다고 픽스가 적용되지 않는 것은 아닙니다. 데이터와보고있는 범위에 따라 추정치가 어느 쪽이든 갈 수 있기 때문에 KB 기사 문구가 정확하지 않다고 생각합니다.

위의 블로그 게시물에서 2014 년부터는 교체가 더 이상 발생하지 않음을 확인했습니다. 안전하기 위해 아마 당신의 술어에서 DATEDIFF를 긁어 내고 다른 방법을 사용하여 범위의 시작을 계산할 것입니다. 과도한 스왑을 방지하기 위해 4199의 오버 킬이나 동적 SQL을 사용하지 않는 것이 좋습니다.