java - 为什么 Microsoft SQL Server 2012 查询比 JDBC 4.0 花费几分钟，但在 Management Studio 中花费几秒钟？

Question

我正在处理一个明显的性能问题，同时检索一个相对较大的 <a href="http://docs.oracle.com/javase/7/docs/api/java/sql/ResultSet.html" rel="noreferrer noopener nofollow">ResultSet</a>从远程 Microsoft SQL Server 2012 到使用 Microsoft JDBC Driver 4.0 的 Java 客户端。

当我在远程服务器的 Microsoft SQL Server Management Studio 上运行相应的查询时，它返回大约。 220k 行几乎是瞬间的。当我从客户端发出相同的查询时，它停止了。同样的测试在使用早期版本数据库的客户端上也运行良好，其中只有大约。 400 行合格。

我试图通过附加 ;responseBuffering=adaptive" 来解决这个问题到传递给 DriverManager.getConnection() 的 URL .建立连接后，我在 connection.getMetaData().getURL() 的结果中看到了这个属性(以及其他几个属性) , 但是[ connection.getClientInfo(responseBuffering) 返回 null , 更重要的是客户端仍然停滞不前。

这里可能出了什么问题，我如何指示 Microsoft SQL Server(不仅仅是建议它——在 Java 中以编程方式)它必须以较小的 block 返回行而不是一次全部返回，或者通过以下方式改进 JDBC 查询时间一些其他措施。

另外两个观察结果看起来有些奇怪，可能指向完全不同的根本原因:

• 当客户端停止时，它仍然只显示相对较轻的 CPU 负载，这与我对大量垃圾收集的预期不同
• "responseBuffering=adaptive"应该是正常的 default现在

更新 我已经检查并发现从 PreparedStatement 切换至 Statement对我的情况没有任何改善(它显然可以帮助 other 个案例)。

更新这是我当前的查询:

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

自适应缓冲是一个很好的答案。我还建议通过 SQL Server Profiler 检查连接的 SET 选项。

开始跟踪时，请确保选择了 ExistingConnections。比较来自 JDBC 连接和 SSMS 连接的 SPID。 ARITHABORT 出现在我的脑海中，因为我看到它会导致 SSMS 和 JDBC 驱动程序之间的性能差异。微软在这里简单提到它: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 上，通过对 Statement/PreparedStatement 对象使用 setFetchSize 方法，我看到了巨大的影响。显然，SQL Server 驱动程序不支持该方法。但是，驱动程序中有一个内部方法。参见 Set a default row prefetch in SQL Server using JDBC driver了解详情。

此外，您在 while (rs.next()) 循环中做什么？尝试只阅读专栏，例如 rs.getInt(1)。走着瞧吧。如果成功，则表明瓶颈出在您之前对结果集的处理中。如果仍然很慢，那么问题一定出在驱动程序或数据库中。

您可以使用 SQL Server Profiler 比较通过 JDBC 进入的执行和通过 SSMS 运行的执行。比较 CPU、读取、写入和持续时间。如果它们不同，则执行计划可能不同，这让我回到了我提到的第一件事:SET 选项。