Quan sát rất thú vị, mặc dù tôi không thể tái tạo nó trên cơ sở dữ liệu Oracle (phiên bản 12.1.0.2.0) của mình. Tôi phải đề cập rằng tôi đang sử dụng Oracle Linux 6.5 chứ không phải Windows.
Cảm ơn bạn rất nhiều vì đã đăng các kế hoạch thực thi, điều này giải thích rất tốt hành vi của truy vấn. Sau đó, tôi sẽ giải thích, bắt đầu với kế hoạch thực hiện đầu tiên:
|* 2 | HASH JOIN | | 1 | 17 | 8 (0)| 00:00:01 |
| 3 | VIEW | | 2 | 14 | 4 (0)| 00:00:01 |
| 4 | SORT UNIQUE | | 2 | | 4 (50)| 00:00:01 |
| 5 | UNION-ALL | | | | | |
| 6 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
| 7 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
| 8 | VIEW | | 2 | 20 | 4 (0)| 00:00:01 |
| 9 | SORT UNIQUE | | 2 | | 4 (50)| 00:00:01 |
| 10 | UNION-ALL | | | | | |
| 11 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
| 12 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
Như bạn có thể thấy, trình tối ưu hóa chọn thực hiện một phép nối bên trong, thay vì phép nối bên trái và điều đó được hiển thị bởi "HASH JOIN" chứ không phải "HASH JOIN OUTER" như bình thường.
Thành thật mà nói, tôi không nghe thấy bất cứ điều gì về một lỗi như thế này (cho đến nay), vì vậy tôi sẽ đề xuất như sau:
- Kiểm tra pfile / spfile nếu nó chứa một số tham số không có tài liệu.
- Có những trường hợp khi thiết lập các thông số này có thể cải thiện hiệu suất, nhưng rất nhiều lần, "nghiệp chướng là ...", như người ta nói và bạn có thể có các hành vi thực thi / hiệu suất không mong muốn theo cách thực sự tồi tệ.