Cách duy nhất tôi có thể nghĩ để có được sự khác biệt về tốc độ thực thi đó là (a) có một chỉ mục trên field4 và (b) có một lô khối dữ liệu trống; có thể từ mốc nước cao được đặt rất cao do tải đường dẫn trực tiếp lặp lại.
Truy vấn đầu tiên sẽ vẫn sử dụng chỉ mục và hoạt động như mong đợi. Nhưng vì giá trị null không được lập chỉ mục, chỉ mục không thể được sử dụng để kiểm tra or field4 is null điều kiện, vì vậy nó sẽ trở lại quá trình quét toàn bộ bảng.
Điều đó tự nó không phải là một vấn đề ở đây, vì quá trình quét toàn bộ bảng gồm 7000 hàng sẽ không mất nhiều thời gian. Nhưng vì nó là mất nhiều thời gian, một cái gì đó khác đang diễn ra. Quá trình quét toàn bộ bảng phải kiểm tra mọi khối dữ liệu được phân bổ cho bảng để xem liệu chúng có chứa bất kỳ hàng nào không và thời gian diễn ra cho thấy có nhiều khối hơn bạn cần giữ 7000 hàng, ngay cả với bộ lưu trữ CLOB nội tuyến.
Cách đơn giản nhất để lấy được nhiều khối dữ liệu trống là có nhiều dữ liệu rồi xóa gần hết. Nhưng tôi tin rằng bạn đã nói trong một nhận xét hiện đã bị xóa về một câu hỏi trước đó rằng hiệu suất từng tốt và đã trở nên tồi tệ hơn. Điều đó có thể xảy ra nếu bạn thực hiện chèn đường dẫn trực tiếp , đặc biệt nếu bạn 'làm mới' dữ liệu bằng cách xóa nó và sau đó chèn dữ liệu mới trong chế độ đường dẫn trực tiếp. Bạn có thể làm điều đó với các phần chèn có /*+ append */ dấu; hoặc song song; hoặc thông qua SQL * Loader. Mỗi lần bạn làm như vậy, dấu nước cao sẽ di chuyển, vì các khối rỗng cũ sẽ không được sử dụng lại; và mỗi lần hiệu suất của truy vấn kiểm tra null sẽ giảm đi một chút. Sau nhiều lần lặp lại, thực sự sẽ bắt đầu tăng lên.
Bạn có thể kiểm tra từ điển dữ liệu để xem có bao nhiêu không gian được phân bổ cho bảng của mình (user_segments v.v.), và so sánh kích thước đó với kích thước của dữ liệu mà bạn nghĩ rằng bạn thực sự có. Bạn có thể đặt lại HWM bằng cách xây dựng lại bảng, ví dụ:bằng cách thực hiện:
alter table mytable move;
(tốt nhất là trong cửa sổ bảo trì!)
Như một bản demo, tôi đã chạy một chu kỳ để chèn đường dẫn trực tiếp và xóa 7000 hàng hơn một trăm lần, và sau đó chạy cả hai truy vấn của bạn. Lần đầu tiên mất 0,06 giây (phần lớn trong số đó là chi phí SQL Devleoper); lần thứ hai lấy 1,260. (Tôi cũng chạy Gordon's, có thời gian tương tự, vì nó vẫn phải làm FTS). Với nhiều lần lặp lại, sự khác biệt sẽ trở nên rõ rệt hơn, nhưng tôi đã hết dung lượng ... Sau đó tôi đã thực hiện alter table move và chạy lại truy vấn thứ hai của bạn, sau đó mất 0,05 giây.
