2012-03-13 33 views
7

Tôi có 98w dữ liệu hàng. Khi tôi muốn sắp xếp dữ liệu của mình với pub_time, tôi đã tìm thấy một điều thú vị.Hai sql cho ngày dấu thời gian được sắp xếp

Đây là SQL:

select * 
from t_p_blog_article_info t 
order by t.pub_time desc 

Nó tốn 19s.

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 

Chi phí là 0,2.

Tôi muốn biết, tại sao?

+0

Có chỉ mục nào trên cột 'pub_time' không? – Ollie

+0

Chỉ cần đoán nhưng t.pub_time có thể là NULL không? – markblandford

+1

dường như mệnh đề where của bạn lọc ra rất nhiều hồ sơ, tại sao? 'null' giá trị, hoặc chỉ đơn giản là mục với giá trị thời gian bị lỗi trước 01.01.1900 – ntziolis

Trả lời

4

Bạn có thể có chỉ mục trên pub_time trên bảng của mình. Do đó, truy vấn thứ hai có thể sử dụng chỉ mục này để chỉ trả về những bản ghi có ngày không rỗng sau ngày được chỉ định, trong khi truy vấn đầu tiên phải truy vấn toàn bộ bảng.

+0

Có tôi có chỉ mục trên pub_time, nhưng tại sao truy vấn đầu tiên không sử dụng chỉ mục? – sarowlwp

+0

Mặc dù, nói đúng, cả hai truy vấn đều phải truy vấn toàn bộ bảng, vì cả hai đều có 'SELECT *' và * có lẽ * cả hai đều trả về tất cả các hàng. (Ít nhất, tôi nghi ngờ OP sẽ hỏi câu hỏi này nếu truy vấn thứ hai trả lại ít hàng hơn.) – ruakh

+0

@sarowlwp: Chỉ mục không bao gồm giá trị null, vì vậy nếu 'pub_time' là nullable (ngay cả khi nó không bao giờ thực sự rỗng), chỉ mục trên nó sẽ không đủ cho truy vấn có mệnh đề WHERE không loại trừ bản ghi nơi nó là null. – ruakh

0

Có nhiều khả năng. Bạn có thể lọc ra số lượng lớn các hàng có ngày không hợp lệ/null trong pub_time, nhưng tôi nghi ngờ rằng bạn không thể chú ý/đề cập đến một số lượng đáng kể trong số này.

Ba điều mà dính ra trong tâm trí của tôi là:

- Bạn có một chỉ số hoặc chỉ số tổng hợp liên quan đến pub_time, và những hạn chế trong bạn mệnh đề where được kích hoạt việc sử dụng một con đường truy cập khác nhau

- Bạn không có sẵn số liệu thống kê cho trình tối ưu hóa khi bạn chạy truy vấn đầu tiên của mình. Khi chạy truy vấn thứ hai, một đường dẫn truy cập tốt hơn đã được chọn nhờ một số bộ đệm thông tin đã xảy ra khi bạn chạy truy vấn đầu tiên. Điều này có thể được xác minh bằng cách chạy truy vấn đầu tiên thêm vài lần nữa và xem liệu có cải thiện hiệu suất đáng kể hay không.

- Tương tự như điểm đầu tiên, trình tối ưu hóa chỉ có thể chọn đường dẫn truy cập tốt hơn chỉ dựa trên tác động của mệnh đề where. Có lẽ đưa ra gợi ý rằng các giá trị null/không hợp lệ sẽ không phải được xử lý là đủ - hệ thống của bạn có thể tránh một hoặc nhiều lần quét bảng đầy đủ để loại bỏ không hợp lệ/null pub_times.

Xác định lý do cho những điều như thế này nhanh chóng trở thành một liên doanh thực nghiệm - thật khó cho tôi để nói nhiều hơn mà không biết nền tảng của bạn & phiên bản. Từ thẻ tôi lấy nó bạn đang sử dụng oracle, trong trường hợp đó bạn sẽ có thể sử dụng một số hình thức "giải thích truy vấn" hoặc "giải thích kế hoạch" công cụ để có được một cảm giác tốt hơn về những gì đang xảy ra. Để biết thêm thông tin về trình tối ưu hóa oracle, hãy xem http://docs.oracle.com/cd/B10500_01/server.920/a96533/optimops.htm (Điều này là dành cho Oracle 9i v9.2, nhưng nó có một giải thích hợp lý về các khái niệm độc lập về phiên bản)

Các vấn đề liên quan