为什么与JDBC 4.0相比，Microsoft SQL Server 2012查询需要几分钟的时间，而在Management Studio中却需要秒？

Question

我正在[ResultSet](http://docs.oracle.com/javase/7/docs/api/java/sql/ResultSet.html)从远程Microsoft
SQL Server 2012到使用Microsoft JDBC Driver 4.0的Java客户端检索相对较大的内容时，显然正在处理性能问题。

当我在远程服务器的Microsoft SQL Server Management
Studio上运行相应的查询时，它返回大约。几乎瞬间达到220k行。当我从客户端发出相同的查询时，它停顿了。使用较早版本的数据库（大约只有）的客户端，相同的测试也可以正常工作。400行合格。

我试图通过附加;responseBuffering=adaptive"到传递给的URL
来解决此问题DriverManager.getConnection()。建立连接后，我在的结果中看到了此属性（还有其他几个属性）connection.getMetaData().getURL()，但是[
connection.getClientInfo(responseBuffering)返回null，并且客户端仍然处于停止状态。

这里可能出了什么问题，以及如何指示Microsoft SQL
Server（不仅以Java编程方式向其提出建议），它必须以较小的块而不是一次全部返回行，或者通过其他一些措施来缩短JDBC查询时间。

另外两个观察似乎有些奇怪，也许完全指向不同的根本原因：

• 当客户端停止运行时，它仍然仅显示相对较轻的CPU负载，这与我对大量垃圾收集的预期不同
• “responseBuffering =自适应”应在正常默认由现在

更新
我已经检查过，发现从我的情况下切换PreparedStatement到Statement并不能改善任何情况（在其他情况下显然可以提供帮助）。

更新 这是我当前的查询：

select 
    PARENT.IDENTIFIER    as PARENT_IDENTIFIER,
    PARENT.CLASS         as PARENT_CLASS,
    CHILD.TYPE           as CHILD_TYPE,
    CHILD.IDENTIFIER     as CHILD_IDENTIFIER,
    PROPERTY.IDENTIFIER  as PROPERTY_IDENTIFIER,
    PROPERTY.DESCRIPTION as PROPERTY_DESCRIPTION,
    PROPERTY.TYPE        as PROPERTY_TYPE,
    PROPERTY.PP          as PROPERTY_PP,
    PROPERTY.STATUS      as PROPERTY_STATUS,
    PROPERTY.TARGET      as PROPERTY_TARGET -- a date
from
    OBJECTS as CHILD
    left outer join RELATIONS              on RELATIONS.CHILD = CHILD.IDENTIFIER
    left outer join OBJECTS    as PARENT   on RELATIONS.PARENT = PARENT.IDENTIFIER
    inner join      PROPERTIES as PROPERTY on PROPERTY.OBJECT = CHILD.IDENTIFIER
where
    PROPERTY.TARGET is not null
order by
    case when PARENT.IDENTIFIER is null then 1 else 0 end,
    PARENT.IDENTIFIER,
    CHILD.IDENTIFIER,
    PROPERTY.TARGET,
    PROPERTY.IDENTIFIER

Answer 1

自适应缓冲是一个很好的答案。我还建议您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选项。