Il buffer adattivo è una buona risposta. Consiglio anche di controllare il SET delle connessioni opzioni tramite SQL Server Profiler.
Quando avvii una traccia, assicurati che ExistingConnections è selezionato. Confronta uno SPID da una connessione JDBC e una connessione SSMS. ARITHABORT mi viene in mente come uno che ho visto causare una differenza di prestazioni tra SSMS e driver JDBC. Microsoft lo menziona brevemente qui:http://msdn.microsoft.com/en-us/library/ms190306.aspx. Stack Exchange informazioni qui:https://dba.stackexchange.com/questions/9840/why-would-set-arithabort-on-dramtically-speed-up-a-query
Su Oracle, ho riscontrato enormi impatti giocando con setFetchSize metodo sulla Statement / PreparedStatement oggetto. Apparentemente, il driver di SQL Server non supporta quel metodo. Tuttavia, esiste un metodo interno nel driver per questo. Per i dettagli, vedere Impostare una precarica di riga predefinita in SQL Server utilizzando il driver JDBC.
Inoltre, cosa stai facendo nel tuo while (rs.next()) ciclo continuo? Prova a non fare altro che leggere una colonna, come rs.getInt(1) . Guarda cosa succede. Se vola, ciò suggerisce che il collo di bottiglia è nella tua precedente elaborazione del set di risultati. Se è ancora lento, il problema deve risiedere nel driver o nel database.
È possibile utilizzare SQL Server Profiler per confrontare le esecuzioni man mano che arrivano tramite JDBC e mentre lo si esegue tramite SSMS. Confronta CPU, letture, scritture e durata. Se sono diversi, probabilmente il piano di esecuzione è diverso, il che mi riporta alla prima cosa che ho menzionato:il SET opzioni.
