Truy vấn chậm trong Java bởi JDBC nhưng không phải trong các hệ thống khác (TOAD)

Question

Xin chào tôi có một truy vấn tới Hệ thống Oracle liên quan đến một khung nhìn nối các bảng khác bằng apliying TO_NUMBER() tới các khóa chính của bảng.

Nếu tôi thực hiện truy vấn bằng TOAD, truy vấn rất nhanh (1 giây cho 800 regs). Nếu tôi làm cùng một truy vấn trong một chương trình java bởi JDBC với một chuỗi ký tự (không phải là một truy vấn parametrized), thời gian là tốt quá.

Nhưng nếu tôi sử dụng truy vấn tham số bằng PreparedStatement, truy vấn sẽ mất 1 phút để tìm nạp cùng một thanh ghi. Tôi biết rằng việc sử dụng các giá trị không đổi tạo ra kế hoạch thực hiện riêng biệt hơn là sử dụng các tham số ... nhưng nếu tôi xóa bỏ TO_NUMBER funcions trong các kết nối của khung nhìn, truy vấn tham số cũng nhanh.

• Các tham số/TO_NUMBER() có ngăn không cho sử dụng chỉ mục PK của các bảng đã tham gia không?
• có giải pháp nào để giải quyết vấn đề này không (tôi cần các tham số trên truy vấn và chức năng TO_NUMBER)?

P.D. sry cho tiếng anh xấu của tôi

Answer 1

không có thông tin bổ sung, chúng tôi chỉ có thể giả định rằng chỉ mục không được sử dụng với hàm to_number() được áp dụng cho cột. Như được hiển thị trong this SO question, một chuyển đổi loại có thể ngăn trình tối ưu hóa sử dụng chỉ mục.

Nói chung:

• khi bạn thêm một chức năng để một cột (ví dụ: to_number(id)) tôi ưu hoa sẽ không thể sử dụng các chỉ số thường xuyên trên cột đó,
• nếu có thể, bạn nên sử dụng cột thô. Ví dụ: thay vì WHERE trunc(col) = DATE '2009-08-27' bạn nên sử dụng: WHERE col >= DATE '2009-08-27' AND col < DATE '2009-08-28'
• nếu bạn thực sự cần phải áp dụng một chức năng để một cột, bạn có thể sử dụng một Kiểm tra function-based index

Answer 2

rằng kiểu dữ liệu của biến Java thông qua trong tham số tương thích với kiểu dữ liệu Oracle. Tôi đã thấy các triệu chứng tương tự như của bạn khi chuyển qua Java TIMESTAMP thông qua biến liên kết đã được so sánh với cột Oracle DATE - truy vấn chuỗi chữ OK, trường hợp kiểm tra trong PL/SQL với (ngày) liên kết OK, mã Java w/không khớp không OK.

[Chỉnh sửa] Tôi nghĩ bạn đã cung cấp một số thông tin bổ sung kể từ khi đăng bài gốc. Cách tốt nhất để hiểu những gì đang xảy ra với các hình thức hơi khác nhau (liên kết so với chữ) của truy vấn từ các môi trường khác nhau (Java so với Toad) là cho phép truy tìm trong khi thực thi và so sánh đường dẫn thực hiện từ các tệp theo dõi kết quả. Điều này sẽ yêu cầu bạn có quyền truy cập vào máy chủ cơ sở dữ liệu để truy xuất các tệp.

• Trong Toad, mở một cửa sổ tương tác SQL (Tôi không sử dụng Toad nhưng tôi chắc chắn bạn sẽ hiểu những gì tôi có nghĩa) và vấn đề lệnh SQL "thay đổi phiên bộ sql_trace = true "
• Chạy truy vấn của bạn - nó sẽ là một ý tưởng tốt để thêm một bình luận với truy vấn chẳng hạn như '/ * Toad với literals * /'
• Đối với thử nghiệm Java, xây dựng một trường hợp thử nghiệm mà phát hành "thay đổi phiên ..." tuyên bố và sau đó chạy truy vấn Một lần nữa, thêm nhận xét để truy vấn để xác định nó như là đến từ các thử nghiệm Java
• Đừng lo lắng về biến truy tìm tắt -.. Điều này sẽ xảy ra khi phiên được ngắt kết nối và trong một số trường hợp các phương pháp ngắt kết nối của dừng các dấu vết được ưa thích.
• Tìm vị trí các file dấu vết của bạn trên host cơ sở dữ liệu là bằng cách "chọn giá trị từ v $ tham số nơi tên như 'user_dump_dest' "
• Tìm các tập tin .trc bằng cách tìm kiếm các dây comment truy vấn
• Sử dụng tiện ích TKPROF từ dòng lệnh OS để xử lý các tập tin dấu vết - "tkprof filename.trc tkprof filename.out"
• Kiểm tra/đăng đường dẫn thực hiện và lần bạn nhìn thấy.

Answer 3

Kiểm tra để chắc chắn rằng ai đó đã không thiết lập thuộc tính oracle.jdbc.defaultNChar = true

này đôi khi được thực hiện để giải quyết vấn đề unicode nhưng nó có nghĩa là tất cả các cột được coi là nvarchars. Nếu bạn có một chỉ mục trên một cột varchar, nó sẽ không được sử dụng bởi vì oracle phải sử dụng một hàm để chuyển đổi mã hóa ký tự.