O buffer adaptativo é uma boa resposta. Eu também recomendaria verificar o SET das conexões opções via SQL Server Profiler.

Ao iniciar um rastreamento, certifique-se de que ExistingConnections é selecionado. Compare um SPID de uma conexão JDBC e uma conexão SSMS. ARITHABORT vem à mente como um que eu vi causar uma diferença no desempenho entre o driver SSMS e JDBC. A Microsoft menciona brevemente aqui:http://msdn.microsoft.com/en-us/library/ms190306.aspx. Stack Exchange informações aqui:https://dba.stackexchange.com/questions/9840/why-would-set-arithabort-on-dramatically-speed-up-a-query

No Oracle, tenho visto grandes impactos ao brincar com o setFetchSize método na Statement / PreparedStatement objeto. Aparentemente, o driver do SQL Server não oferece suporte a esse método. No entanto, existe um método interno no driver para isso. Consulte Definir uma pré-busca de linha padrão no SQL Server usando o driver JDBC para obter detalhes.

Além disso, o que você está fazendo em seu while (rs.next()) ciclo? Tente não fazer nada além de ler uma coluna, como rs.getInt(1) . Veja o que acontece. Se ele voar, isso sugere que o gargalo está no seu processamento anterior do conjunto de resultados. Se ainda estiver lento, o problema deve estar no driver ou no banco de dados.

Você pode usar o SQL Server Profiler para comparar as execuções conforme elas chegam via JDBC e conforme você as executa via SSMS. Compare a CPU, leituras, gravações e duração. Se forem diferentes, o plano de execução provavelmente é diferente, o que me leva de volta à primeira coisa que mencionei:o SET opções.