정렬 된 타임 스탬프 날짜를위한 두 개의 SQL

Question

98W 행 데이터가 있습니다.PUB_TIME으로 데이터를 정렬하기를 원할 때 나는 관심사를 발견했습니다.

여기에 SQL :

select * 
from t_p_blog_article_info t  
order by t.pub_time desc

.

비용은 19 초입니다.

select * 
from t_p_blog_article_info t 
where t.pub_time > to_date( '1900-01-01 01:00:00', 'yyyy-mm-dd   hh24:mi:ss ')  
order by t.pub_time desc

.

비용이 0.2s입니다.

알고 싶습니다. 왜?

Answer 1

테이블에 PUB_TIME에 인덱스가있을 것입니다.

따라서 두 번째 쿼리는 지정된 날짜 이후의 null이 아닌 날짜가 아닌 레코드 만 반환하는 반환하여 첫 번째 쿼리가 전체 테이블을 쿼리해야합니다.

Answer 2

다양한 가능성이 있습니다. PUB_TIME에서 유효하지 않은 / NULL 날짜가있는 많은 수의 행을 필터링 할 수 있지만 이들 중 많은 수의 숫자를 알아 내거나 언급하지 않아도됩니다.

내 마음 속에 튀어 나오는 세 가지가 있습니다 :

1 - pub_time과 관련된 인덱스 또는 복합 인덱스가 있고 WHERE 절의 제한이 다른 액세스 경로의 사용을 트리거하고 있습니다

2 - 첫 번째 쿼리를 실행할 때 최적화 프로그램에 사용할 수있는 통계가 없었습니다. 두 번째 쿼리를 실행할 때 첫 번째 쿼리를 실행했을 때 발생한 일부 정보 캐싱 덕분에 더 나은 액세스 경로가 선택되었습니다. 이것은 몇 번 더 많은 쿼리를 실행하고 중요한 성능 향상이 있는지 확인하여 확인할 수 있습니다.

3 - 첫 번째 점과 유사하게, 옵티마이 저는 WHERE 절의 시사점에 따라보다 나은 액세스 경로를 선택할 수 있습니다. 아마도 null / 유효하지 않은 값을 처리 할 필요가없는 힌트를 제공 할 수 있습니다. 시스템이 무효 / Null PUB_TIMES에 대해 하나 이상의 전체 테이블 스캔을 피할 수 있습니다.

이런 것들에 대한 이유를 정확히 정확하게 경험적 벤처 기업이되는 것은 당신의 플랫폼 및 버전을 알지 못하지 않으면 서 더 많은 것을 말하기가 어렵습니다. 태그에서 나는 Oracle을 사용하고 있으며이 경우 어떤 형태의 "Explain 쿼리"또는 "설명 계획"도구를 사용하여 무슨 일이 일어나는지 더 잘 이해할 수 있어야합니다. Oracle Optimizer에 대한 자세한 내용은 http://docs.oracle .com / cd / b10500_01 / server.920 / a96533 / opptops.htm (이것은 Oracle 9i V9.2 용이지만 버전 독립적 인 개념에 대한 적절한 설명이 있습니다)