I 간단한 쿼리를 실행 :Netezza : 쿼리 상세 계획에서 WHERE 절이 예상 행 수에 어떤 영향을 줍니까?
SELECT * FROM TABLE1
WHERE ID > 9 AND ID < 11
쿼리 상세 계획이다
[SPU 순차 검색 테이블 "TABLE1"{(. TABLE1 "ID")}]
- 예상 행 = 1은 ...
그러나 이후
는 에 where 절을 변경WHERE ID = 10
쿼리 상세 계획 변경 :
[SPU 순차 검색 테이블 "TABLE1"{(. TABLE1 "ID")}]
- 기준 행 = 1000 ...
(여기서 1000은 TABLE1의 총 행 수).
왜 그렇습니까? 견적은 어떻게 작동합니까?
모든 비용 기반 데이터베이스의 최적화 프로그램은 항상 놀라움으로 가득합니다. 익숙한 플랫폼에서이 스크립트는 일반적이지 않습니다.
몇 가지 질문 : - 테이블에 대한 통계를 만들었습니까? (그렇지 않으면 블라인드를 날고있다) - 그 열에 대한 데이터 유형은 무엇인가? (y = 0 인 경우에도 NUMBER (x, y)가 아닌 정수 일 수 있습니다.)
더 : netezza의 열에 대한 통계에는 분포 통계가 포함되어 있지 않습니다 5 년 분량의 데이터가있는 지원 시스템 테이블에 "해결되지 않은"사례보다 "해결 된"사례가있는 경우). 그 대신에 다음 두 가지에 의존합니다 : 1) 모든 테이블에 대해 : 단순 통계 (고유 값 수, 최대 + 최소값, 널 수) 2) large'ish 테이블의 경우 (구성 가능한 최소값 는 100 밀 행에 가깝습니다.) 데이터 복제본에서 몇 개의 무작위 데이터 페이지를 스캔하여 JIT syatistics (Just In Time)를 생성하고이 쿼리에 대한 통계를 작성합니다.
쿼리의 계획 단계에 런타임을 추가하더라도 마지막 기능은 실제로 매우 강력합니다. 테이블의 두 whereclause 사이에 몇 가지 상관 관계가있는 경우이를 고려할 가능성이 상당히 높아집니다. 예 : 대도시의 모든 시민 목록에서 (AGE> 60 및 Retired = true)에 대한 where 절. AGE 제한을 추가하는 것이 거의 불가능할 수도 있습니다. Netezza는이를 알게 될 것입니다.
일반적으로 netezza를 사용하여 예상되는 행 수에 대해 걱정할 필요가 없습니다.이 경우 대부분의 경우 "적절 함"을 얻고 하드웨어를 사용하여 사소한 실수를 보완합니다. .
최근까지 필자는 notorius (새로운 버전에서는 더 좋음) SQL Server와 협력하여 where 절의 가치에 지나치게 낙관적이었고 수백 레벨의 행과 함께 5 단계의 중첩 루프 조인을 사용하여 액세스 계획을 마무리했습니다. 각각 6 개의 테이블을 결합 할 때.질문에서와 같이 where 절을 변경하면 sqlserver가 특정 제한에 대해 LESS empathesis를 넣을 수 있으며 이로 인해 5 개 조인이 더 효율적인 해시 또는 다른 알고리즘이되어 성능이 향상 될 수 있습니다. 필자의 경험으로 볼 때 너무 많이 예상되는 것에 너무 많이 의존하는 데이터베이스의 경우가 너무 많습니다. 아마도 최적화 프로그램이웨어 하우스와 같은 작업 부하에 맞게 작성/조정되지 않았기 때문일 수 있습니다.