La mise en mémoire tampon adaptative est une bonne réponse. Je recommanderais également de vérifier les connexions SET options via SQL Server Profiler.
Lorsque vous démarrez une trace, assurez-vous que ExistingConnections est sélectionné. Comparez un SPID d'une connexion JDBC et d'une connexion SSMS. ARITHABORT vient à l'esprit comme celui que j'ai vu causer une différence de performances entre SSMS et le pilote JDBC. Microsoft le mentionne brièvement ici :http://msdn.microsoft.com/en-us/library/ms190306.aspx. Informations sur Stack Exchange ici :https://dba.stackexchange.com/questions/9840/why-would-set-arithabort-on-dramatically-speed-up-a-query
Sur Oracle, j'ai vu d'énormes impacts en jouant avec le setFetchSize méthode sur la Statement / PreparedStatement objet. Apparemment, le pilote SQL Server ne prend pas en charge cette méthode. Cependant, il existe une méthode interne dans le pilote pour cela. Voir Définir une prélecture de ligne par défaut dans SQL Server à l'aide du pilote JDBC pour plus de détails.
Aussi, que faites-vous dans votre while (rs.next()) boucle? Essayez de ne rien faire d'autre que de lire une colonne, comme rs.getInt(1) . Voyez ce qui se passe. S'il vole, cela suggère que le goulot d'étranglement se trouve dans votre ancien traitement de l'ensemble de résultats. S'il est toujours lent, le problème doit provenir du pilote ou de la base de données.
Vous pouvez utiliser SQL Server Profiler pour comparer les exécutions au fur et à mesure qu'elles arrivent via JDBC et lorsque vous l'exécutez via SSMS. Comparez le CPU, les lectures, les écritures et la durée. S'ils sont différents, alors le plan d'exécution est probablement différent, ce qui me ramène à la première chose que j'ai mentionnée :le SET options.
