2011-09-05 5 views
0

다음 쿼리에서 테이블 title_deed에 대한 조인은 title_deed_no 검색 조건에만 필요하며 필드를 선택하지 않습니다. @titleDeedNumber 매개 변수가 null 인 경우 여전히 조인이 수행됩니까? 어쨌든 성능 차이는 어느 정도입니까? 큰 못생긴 T-SQL 문자열의 동적 생성을 대체하려고 시도하고 있으며 그 코드는 title_deed_no 값이 제공된 경우에만 조인을 추가합니다.필요없는 경우 SQL Server 2008에서 조인을 최적화합니까?

DECLARE @registrarId nchar(1) 
DECLARE @titleDeedNumber nvarchar(50) 

SELECT TOP 100 
     vw.* 
FROM ACC.dbo.vw_Property_Nad vw 
     INNER JOIN title_deed td ON (@titleDeedNumber IS NULL) 
            OR (td.Prop_ID = vw.prop_id) 
WHERE vw.Prop_ID IS NOT NULL 
     AND Registrar = isnull(@registrarId, vw.Registrar) 
     AND td.title_deed_no = isnull(@titleDeedNumber, td.title_deed_no) 

나는 실행 계획을 examning 시도,하지만 vw_Property_Nad보기에서 조인에 너무 바쁘다, 나는 오히려 어쨌든 전문가의 의견을 얻을 것입니다.

+1

참여를 제거 할 때 성능에 미치는 영향은 처음부터 참여하는 전체 비용의 양에 따라 다릅니다. 'INNER JOIN' 대신에 'LEFT OUTER JOIN'을하고'WHERE '대신에 ON 절에'title_deed_no' 체크를 포함시켜야하는 이유는 무엇입니까? 계획이 너무 바쁜 경우 간단한보기 또는 표로 유사한 시나리오를 재구성하지 않는 이유는 무엇입니까? –

+0

(@titleDeedNumber가 NULL 일 때와 같이) 조인 조건이 없다면 CROSS JOIN과 같지 않습니까? – Magnus

답변

2

이 경우에는 그렇지 않습니다.

당신은 더 나을 것 :

  • 이 가입하지 EXISTS (즉, 반 조인 조인 동등하지 않음)는
존재에 td.title_deed_no에 대한
  • (vw.Registrar = @registrarId OR @registrarId IS NULL)
  • 저두을

    • TOP BY는 쓸모가 없다.
    • 당신의 JOIN 조건은 CROSS JOIN을 의미한다. - 작동하려면 DISTINCT가 필요하다.
    • vw는 뷰가 의미하는 것보다 더 복잡하다. 뷰는

    나는 또한 IF 또는 UNION ALL

    SELECT 
         vw.* 
    FROM ACC.dbo.vw_Property_Nad vw 
    WHERE vw.Prop_ID IS NOT NULL 
         AND (vw.Registrar = @registrarId OR @registrarId IS NULL) 
         AND @titleDeedNumber IS NULL 
    UNION ALL 
    SELECT 
         vw.* 
    FROM ACC.dbo.vw_Property_Nad vw 
    WHERE vw.Prop_ID IS NOT NULL 
         AND (vw.Registrar = @registrarId OR @registrarId IS NULL) 
         AND @titleDeedNumber IS NOT NULL 
         AND EXISTS (...) 
    ORDER BY something 
    
  • +0

    유용한 입력을 주셔서 감사합니다. 그러나'@ titleDeedNumber'가 몇 가지 기준 중 첫 번째 임에도 불구하고 UNION 제안을 사용할 수 없습니다. – ProfK

    1

    난 당신이 멀리 최적화 할 가입 싶어 모르겠어요를 생각 하는데요 확장 매크로이다. 이는 매개 변수에 따라 최소 두 개의 다른 계획이 있음을 의미합니다. 즉 매개 변수가 제공되고 캐시 된 계획이 NULL (또는 그 반대)으로 저장되는 경우 최적이 아니거나 잠재적으로 유효하지 않음을 의미합니다. 이것이 궁극적으로 달성하고자하는 것이라면 두 개의 다른 저장 프로 시저를 사용하여 매개 변수가 채워 졌는지 여부에 따라 호출 할 프로 시저를 결정하십시오.

    중요한 계획/성능 차이가 실제로 나는 경우에만 수행하십시오. @bbn 상태로, 제목 증서 테이블이 거대하고 인덱싱되지 않은 (또는 최적으로 인덱싱되지 않은) 경우가 아니면이 경우 큰 성능 차이가 발생할 것입니다. 이에 대한 일반적인 접근법은 OR 값이 NULL임을 확인하는 것입니다. 다중 프로 시저 접근법은 단 하나의 선택적 매개 변수를 사용하더라도 일반적으로 거의 이익을 위해 유지 보수하는 것이 훨씬 지루하며, 하나 이상의 선택적 매개 변수로 구성됩니다.

    아주 좋은 배경 자료를 보려면 Erland Sommarskog의 문서 Dynamic Search Conditions (2008-specific version)을 확인하십시오.

    +0

    기사 주셔서 감사합니다. 좋은 읽을 것 같습니다. BTW, 표창장 테이블은 7.5m 행에서 크지 만보기 좋게 색인 된 것으로 보이며 엄청나게 거대하지 않습니다. – ProfK

    관련 문제