문제

DB2에서는 Null을 인덱싱할 수 없다는 것이 제가 이해한 바입니다. 따라서 일반적으로 날짜이지만 때때로(10%의 경우) Null인 날짜 열(sold_on)이 있는 거대한 테이블(Sales)이 있다고 가정합니다.

또한 변경할 수 없는 레거시 애플리케이션이므로 해당 null이 거기에 남아 있고 무언가를 의미한다고 가정해 보겠습니다(예를 들어 반환된 매출).

Sell_on 및 total 열에 인덱스를 추가하면 다음 쿼리를 빠르게 만들 수 있습니다.

Select * from Sales 
where 
Sales.sold_on between date1 and date2
and Sales.total = 9.99

그러나 인덱스는 이 쿼리를 더 빠르게 만들지 않습니다.

Select * from Sales 
where 
Sales.sold_on is null
and Sales.total = 9.99

인덱싱이 값에 대해 수행되기 때문입니다.

Null을 인덱싱할 수 있나요?아마도 인덱스 유형을 변경하면 될까요?표시기 열을 인덱싱하시겠습니까?

도움이 되었습니까?

해결책

저는 DB2 전문가는 아니지만 값의 10%가 null인 경우 해당 열의 인덱스만으로는 쿼리에 도움이 되지 않을 것이라고 생각합니다.10%는 인덱스를 사용하기에는 너무 많은 양입니다. 테이블 스캔만 수행하게 됩니다.2~3% 정도 말씀하셨다면 실제로는 지수를 활용하실 것 같습니다.

페이지/블록에 레코드 수(예: 20개)가 있는지 생각해 보세요.인덱스를 사용하는 이유는 필요하지 않은 페이지를 가져오는 것을 피하기 위해서입니다.특정 페이지에 Null인 레코드가 0개 포함될 확률은 (90%)^20 또는 12%입니다.이는 좋은 확률이 아닙니다. 어쨌든 가져오려면 페이지의 88%가 필요하므로 색인을 사용하는 것은 그다지 도움이 되지 않습니다.

그러나 select 절에 *가 아닌 몇 개의 열만 포함된 경우(예: salesid만) 데이터 페이지 읽기가 불가능하므로 (sold_on,salesid)에 대한 인덱스를 사용하도록 할 수 있습니다. 필요 - 모든 데이터가 인덱스에 포함됩니다.

다른 팁

DB2가 NULL을 인덱싱하지 않는다는 인상을 어디서 얻었습니까?주장을 뒷받침하는 문서나 기사에서 아무것도 찾을 수 없습니다.그리고 방금 NULL의 작은 부분을 포함하는 인덱스 열과 관련된 IS NULL 제한을 사용하여 큰 테이블에서 쿼리를 수행했습니다.이 경우 DB2는 확실히 인덱스를 사용했습니다(EXPLAIN으로 확인하고 테이블 스캔을 수행하는 데 시간을 소비하는 대신 데이터베이스가 즉시 응답하는 것을 관찰하여 확인함).

그래서:나는 DB2가 기본 키가 아닌 인덱스의 NULL과 관련하여 아무런 문제가 없다고 주장합니다.

그러나 다른 사람들이 쓴 것처럼:DB2가 인덱스를 사용하는 것이 더 빠르지 않다고 생각하는 방식으로 데이터가 구성될 수 있습니다.또는 관련 테이블에 대한 데이터베이스 통계가 최신이 아닙니다.

경험상 인덱스는 레코드의 최대 15%에 해당하는 값에 유용하다는 것입니다....따라서 여기서는 색인이 유용할 수 있습니다.

DB2가 null을 인덱싱하지 않으면 부울 필드인 IsSold를 추가하고 Sell_on 날짜가 설정될 때마다 이를 true로 설정하는 것이 좋습니다(이 작업은 트리거에서 수행할 수 있음).

이것이 가장 좋은 해결책은 아니지만 필요한 것일 수도 있습니다.

Troels가 맞습니다.SOLD_ON 값이 NULL인 행도 해당 열의 인덱스를 사용하면 이점을 얻을 수 있습니다.SOLD_ON에서 범위 검색을 수행하는 경우 SOLD_ON으로 시작하는 클러스터형 인덱스를 생성하면 더 많은 이점을 얻을 수 있습니다.이 특정 예에서는 추가된 새 행이 최신 SOLD_ON 날짜를 가질 가능성이 높기 때문에 SOLD_ON을 기반으로 클러스터링 순서를 유지하는 데 추가 오버헤드가 많이 필요하지 않을 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top