Bộ đệm thích ứng là một câu trả lời tốt. Tôi cũng khuyên bạn nên kiểm tra các kết nối 'SET tùy chọn thông qua SQL Server Profiler.
Khi bạn bắt đầu theo dõi, hãy đảm bảo ExistingConnections đã được chọn. So sánh SPID từ kết nối JDBC và kết nối SSMS. ARITHABORT nhớ đến như một điều mà tôi đã thấy gây ra sự khác biệt về hiệu suất giữa trình điều khiển SSMS và JDBC. Microsoft đề cập ngắn gọn về nó tại đây:http://msdn.microsoft.com/en-us/library/ms190306.aspx. Thông tin về Stack Exchange tại đây:https://dba.stackexchange.com/questions/9840/why-would-set-arithabort-on-dramatically-speed-up-a-query
Trên Oracle, tôi đã thấy những tác động to lớn khi chơi với setFetchSize trên Statement / PreparedStatement vật. Rõ ràng, trình điều khiển SQL Server không hỗ trợ phương pháp đó. Tuy nhiên, có một phương pháp nội bộ trong trình điều khiển cho nó. Xem Đặt tìm nạp trước hàng mặc định trong SQL Server bằng trình điều khiển JDBC để biết chi tiết.
Ngoài ra, bạn đang làm gì trong while (rs.next()) của mình vòng? Hãy thử không làm gì khác ngoài việc đọc một cột, như rs.getInt(1) . Hãy xem điều gì sẽ xảy ra. Nếu nó bay, điều đó cho thấy nút cổ chai nằm trong quá trình xử lý trước đây của bạn đối với tập kết quả. Nếu nó vẫn chậm, thì sự cố phải nằm ở trình điều khiển hoặc cơ sở dữ liệu.
Bạn có thể sử dụng SQL Server Profiler để so sánh các thực thi khi chúng đến qua JDBC và khi bạn chạy nó qua SSMS. So sánh CPU, đọc, ghi và thời lượng. Nếu chúng khác nhau, thì kế hoạch thực thi có thể khác, điều này khiến tôi quay trở lại điều đầu tiên tôi đã đề cập:SET tùy chọn.
