自适应缓冲是一个很好的答案。我还建议您
SET通过SQL Server Profiler 检查连接的选项。
开始跟踪时，请确保
ExistingConnections已选择。比较来自JDBC连接和SSMS连接的SPID。
ARITHABORT想到的是，我所看到的会导致SSMS和JDBC驱动程序之间的性能差异。Microsoft在这里简短地提到了它：http : //msdn.microsoft.com/en-
us/library/ms190306.aspx。在此处堆栈交换信息：https :
//dba.stackexchange.com/questions/9840/why-would-set-arithabort-on-
dramatically-speed-up-a-
query
在Oracle上，通过
setFetchSize在
Statement/
PreparedStatement对象上使用该方法，我看到了巨大的影响。显然，SQL
Server驱动程序不支持该方法。但是，驱动程序中有一个内部方法。有关详细信息，请参见使用JDBC驱动程序在SQLServer中设置默认行预取。
另外，您在
while(rs.next())循环中做什么？除了阅读专栏外，请尝试进行其他操作，例如
rs.getInt(1)。走着瞧吧。如果一切顺利，则表明瓶颈在于您以前对结果集的处理。如果仍然很慢，则问题必须出在驱动程序或数据库中。
您可以使用SQL Server
Profiler比较通过JDBC和通过SSMS运行的执行。比较CPU，读取，写入和持续时间。如果它们不同，则执行计划可能会有所不同，这使我回到我提到的第一件事：
SET选项。
