sql server查询在java中运行缓慢

我有一个java程序，它对sql server数据库运行一系列查询。其中第一个查询视图，返回大约750k条记录。我可以通过SQLServerManagementStudio运行查询，在大约30秒内得到结果。然而，我昨晚启动了运行的程序。当我今天早上检查它时，这个查询仍然没有返回结果给java程序，大约15小时后

我可以访问数据库做任何我想做的事情，但我真的不知道如何开始调试这个。我们应该怎么做才能弄清楚是什么导致了这样的局面？我不是dba，对sql server工具集也不是很熟悉，因此如果您能给我更多关于如何执行建议的详细信息，我将不胜感激

这是密码

stmt = connection.createStatement();
clientFeedRS = stmt.executeQuery(StringBuffer.toString());

编辑1：

好吧，已经有一段时间了，这个问题被转移了，但这个问题又回来了。我曾考虑过从jdbc驱动程序V1.2升级到2.0，但我们仍停留在JDK1.4上，而V2.0需要JDK1.5，所以这是一个非初学者。现在我正在查看我的连接字符串属性。我看这可能有用

SelectMethod=cursor|direct
responseBuffering=adaptive|full

目前，由于延迟问题，我使用cursor作为selectMethod运行，responseBuffering的默认值为full。更改这些属性是否有帮助？如果是，理想的设置是什么？根据我在网上找到的资料，我认为使用直接选择方法和自适应响应缓冲可能会解决我的问题。有什么想法吗

编辑2：

---

最后，我使用默认的select方法（direct）更改了这两个连接字符串参数，并将responseBuffering指定为adaptive。这对我来说效果最好，并且缓解了我所看到的延迟问题。感谢您的帮助。

收回这么多数据需要很多时间。您可能应该找到一种方法，在任何给定的时间都不需要应用程序中有那么多数据。例如，对数据进行分页或使用。如果没有更多关于您要完成什么的详细信息，很难说。

从management studio运行时速度很快，这可能是由于缓存的查询计划不正确和索引过期（例如，由于大量导入或删除）。是否在SSMS中快速返回所有750K记录

---

尝试重建索引（或者，如果需要太长时间，请更新统计数据）；可能会刷新过程缓存（如果这是一个生产系统，请小心……）：要开始调试，最好确定问题区域是在数据库中还是在应用程序中。您是否尝试过更改查询，使其返回更小的结果？如果没有返回，我建议以从Java访问DB的方式为目标

使用SQLWB需要相似的时间吗？如果Java版本慢得多，那么我会检查以下几点：

您应该使用仅向前、只读的结果集获得最佳性能

我记得MSFT中较旧的JDBC驱动程序速度较慢。确保您使用的是最新的n-best。我认为有一个通用的SQL Server one和一个专门用于SQL 2005的SQL Server one

---

确保您的JDBC驱动程序配置为使用直接连接，而不是基于cusror的连接。如果不确定，可以发布JDBC连接URL

确保使用的是只读的正向结果集（如果未设置，则为默认结果集）

并确保您正在使用更新的JDBC驱动程序

如果所有这些都不起作用，那么您应该查看sql探查器，并在jdbc驱动程序执行语句时尝试捕获sql查询，然后在ManagementStudio中运行该语句，看看是否有差异

---

此外，由于要提取如此多的数据，您应该尝试确保JVM上没有任何内存/垃圾收集速度减慢（尽管在本例中，这并不能真正解释时间差异）。

尝试调整语句的获取大小，并尝试使用游标的selectMethod

我们在使用mysql的大型结果集时遇到了问题，需要让它像下面的链接中所解释的那样对结果集进行流式处理

---

如果查询被参数化，它可能是缺少的参数，或者是使用错误的函数设置的参数，例如setLong for string等。

---

尝试使用硬编码到查询正文中的所有参数运行您的查询，而不使用任何

？

，以查看是否存在此问题。

引用MS Adaptive buffer指南：

避免使用连接字符串属性selectMethod=cursor来允许应用程序处理非常大的结果集。自适应缓冲功能允许应用程序在不使用服务器游标的情况下处理非常大的前向只读结果集。请注意，当设置selectMethod=cursor时，该连接生成的所有正向只读结果集都会受到影响。换句话说，如果您的应用程序例行地处理只有几行的短结果集，那么为每个结果集创建、读取和关闭服务器游标将比selectMethod未设置为游标使用更多的客户端和服务器端资源

及

在某些情况下，使用selectMethod=cursor而不是responseBuffering=adaptive更为有利，例如：

• 如果应用程序缓慢地处理一个只读的前向结果集，例如在用户输入后读取每一行，那么使用selectMethod=cursor而不是responseBuffering=adaptive可能有助于减少SQL Server的资源使用

• 如果您的应用程序在同一连接上同时处理两个或多个仅向前、只读的结果集，则在处理这些结果集时，使用selectMethod=cursor而不是responseBuffering=adaptive可能有助于减少驱动程序所需的内存

  Query query = em().createNativeQuery(queryString)                    
                  .setParameter("param", SomeEnum.DELETED.name())
  

  jdbc:jtds:sqlserver://YourSqlServer.name:1433/DefaultDbName