SARGability에 대한 질문

나는 무언가를 올바르게 이해하고 있음을 확인해야합니다.

최근에 사용자가 Linq에 다음과 같은 답변을 게시 한 SO 질문을 보았습니다.

from p in db.table where p.column.AddMinutes(1) > DateTime.Now select p

Linq에 익숙하지 않은 사람들에게는 그 진술의 결과 (공평하게 테스트되지 않음)가 다음과 같을 것으로 기대합니다.

SELECT *
FROM table t
WHERE DATEADD(min, 1, t.column) >= GETDATE() 

나는 날짜 시간 조작이 변수 (이 경우 GETDATE())에 있어야한다는 사실 에 대한 답변을 게시 했으므로 실제로 진술은 다음과 같이 반영되어야합니다.

SELECT *
FROM table t
WHERE t.column >= DATEADD(min, -1, GETDATE())

내 대답에서, 내가 확신하지 못하는 비트는 다음을 가정합니다.

1. 컬럼 조작으로 인해 인덱스가 사용되지 않습니다
2. 위의 이유로 인해 쿼리 계획이 부분적으로 다를 수 있습니다 (테스트되지 않은 경우)
3. 위의 이유로 인해 첫 번째 쿼리는 실제로 두 번째 쿼리보다 성능이 떨어집니다.

내 질문:

추론에서 빠진 것이 있습니까? 나 맞아? 마지막으로, 어떤 신체에 SARGability에 관한 좋은 기사가 있습니까?

1. 옳은
2. 반드시 그런 것은 아닙니다. 적합한 인덱스가 있는지 여부와 CBO가 해당 인덱스를 사용하기로 결정했는지 여부에 따라 다릅니다. 예를 들어, 테이블이 작거나 통계로 인해 옵티마이 저가 많은 비율의 결과에 대해 필터가 참이라고 믿게하는 경우 FTS 비용이 더 낮은 것으로 간주 할 수 있습니다
3. 이것이 보장되지는 않습니다-심지어 두 번째 쿼리가 더 나빠질 수도 있습니다. 그러나 당신의 추론은 근본적으로 좋습니다. 예를 들어, FTS가 실제로 더 빠른 경우의 경우 CBO는 비용에 대한 최선의 추측을 기반으로 인덱스 스캔을 선택할 수 있습니다.

약간의 인터넷 검색 으로이 SO 질문 과 SARGability에 대한 흥미로운 흥미로운 기사 가 나왔습니다.

잭이 맞아 반복하지 않겠습니다.

표현의 Sargability와 관련하여 내가 좋아하는 기사를 추가하겠습니다.

• Sargability : % string %가 느린 이유 -(내가 가장 좋아하는) Brent Ozar
• Sargable 식의 행잉 과일-Dan Guzman
• SQL Server Transact-SQL WHERE- 작성자 : Brad McGehee
• Sargable 술어 -Jeff Wharton
• OR에 대한 인덱싱 -Gail Shaw

그들은 모두 SQL Server 경험이 많은 훌륭한 작가입니다.