Adaptacyjne buforowanie to dobra odpowiedź. Polecam również sprawdzenie połączeń SET opcje za pośrednictwem programu SQL Server Profiler.
Po uruchomieniu śledzenia upewnij się, że ExistingConnections jest zaznaczone. Porównaj identyfikator SPID z połączenia JDBC i połączenia SSMS. ARITHABORT przychodzi mi na myśl, ponieważ widziałem, jak powoduje różnicę w wydajności między sterownikiem SSMS i JDBC. Microsoft krótko o tym wspomina tutaj:http://msdn.microsoft.com/en-us/library/ms190306.aspx. Informacje o wymianie stosu znajdują się tutaj:https://dba.stackexchange.com/questions/9840/why-would-set-arithabort-on-dramatically-speed-up-a-query
W przypadku Oracle zauważyłem ogromny wpływ, bawiąc się setFetchSize metoda na Statement / PreparedStatement obiekt. Najwyraźniej sterownik SQL Server nie obsługuje tej metody. Jednak w sterowniku jest na to wewnętrzna metoda. Aby uzyskać szczegółowe informacje, zobacz Ustawianie domyślnego wstępnego pobierania wierszy w SQL Server przy użyciu sterownika JDBC.
Ponadto, co robisz w swoim while (rs.next()) pętla? Spróbuj nie robić nic poza czytaniem kolumny, na przykład rs.getInt(1) . Zobacz co się dzieje. Jeśli leci, sugeruje to, że wąskie gardło znajduje się w poprzednim przetwarzaniu zestawu wyników. Jeśli nadal działa wolno, problem musi dotyczyć sterownika lub bazy danych.
Możesz użyć programu SQL Server Profiler do porównania wykonań przychodzących przez JDBC i uruchamianych przez SSMS. Porównaj procesor, odczyty, zapisy i czas trwania. Jeśli są różne, to prawdopodobnie plan wykonania jest inny, co wskazuje mi na pierwszą rzecz, o której wspomniałem:SET opcje.
