针对Hyper-V VM中运行的SQL服务器诊断慢速JDBC选择语句

Question

我们刚刚构建了一个新的Hyper-V虚拟机来托管Java应用程序和MicrosoftSQL服务器。在运行JavaJDBC应用程序的SQL选择查询时，我们遇到了数据库响应极其缓慢的问题。从SQL服务器管理工作室运行时，同样的查询执行速度很快。

我们已经在裸机和VMware虚拟机上运行了相同的Java应用程序和SQL Server数据库，没有出现任何性能问题。

我们的问题：

• 其他开发人员是否在Hyper-V虚拟机中看到过类似的性能问题？
• 我们如何诊断导致JDBC应用程序性能瓶颈的原因？

示例查询：

select * from view1 where app_id in (
    select app_id from app_table where app_id % 1000 = 0)
order by app_id

响应时间:

• SQL Server：45 到 9 秒内 36k 行，具体取决于 RAM、CPU 等
• Java 应用程序：超过 4 小时

Hyper-V虚拟机

• Windows Server 2019 主机
• Hyper-V 配置 9，第 2 代

app_table表只有两列。

create table app_table (
  app_id [numeric](18,0) not null,
  col_2 [varchar] (75)
)

app_view视图也很简单。

create view app_view as select app_id from app_table

我们已经尝试了Java应用程序，JDBC驱动程序和SQL Server的各种组合。

应用:

• 我们的定制Java应用程序
• SQuirreL客户端（4.0.0）

JDBC司机:

• sqljdbc4
• sqljdbc_8.2.0.jre

SQL Server版本:

• SQL服务器2017
• SQL服务器2019

Java版本：8_241

我不确定报告 SQL 分析结果的最佳方式，因此我只总结一下 SQL 事件探查器报告的内容。SSMS 客户端在 23 秒内执行视图查询。JDBC 客户端在完成查询之前花费了 100 多秒的时间。

SQL： Batch开始"选择*从app_view…"2020-02-26 20:04:22

SQL:batch starting " select * from app _ view where ... "2020-02-26 19:55:39

我在 SSMS 和 JDBC 客户端中分析了更简单的查询“从 app_table a 中选择前 5000 个 a.app_id”。令人惊讶的是，两者都在不到 1 秒的时间内快速执行。

SQL： Batch开始"前5000名a.app_id从app_table"2020-02-27 10:27:55.740
SQL： Batch完成"前5000名a.app_id从app_table"2020-02-27 10:27:55.810

SQL:BatchStarting“top 5000 a.app_id from app_table a”2020-02-27 10:25:45.63
SQL:Batch Completed“top 5000.app_id for app_table”2020-03-27 10:25：45.843

Answer 1

好的，所以我们得到了这些结果。

编辑：

对这个问题的简短回答是：客户端不应该太重要（即：SSMS与. Net与JDBC等之间不应该有那么大的差异）就Hyper-V与裸机而言，裸机获胜（假设您的磁盘是虚拟化的），原因很明显。您可以在VM与类似规格的裸机环境中使用DiskSpd（https://aka.ms/diskspd）运行一些I/O测试来证明这一点。

然而-我还不相信这些因素中的任何一个是问题所在。根据您的跟踪结果，两个客户端在基表上的表现都很好。两个客户端在视图上的表现都相对较差（Java客户端比SSMS差）。所以，我仍然建议，至少：

>

刷新视图（如前所述）

尝试一个简单的SELECT TOP 5000*FROM dbo。app_view（来自两个客户端）-不带任何WHERE子句-比较结果

在SSMS中检查基础表上的索引碎片（右键单击表下的索引“文件夹”，单击“全部重建”，查看对话框中的数字。）甚至PK索引也可能变得碎片化，这可能导致性能变得不稳定。

尝试原始查询的不同版本，例如:

选择*从dbo.app_view其中app_id%1000=0

（没有SELECT…WHERE IN…）

最后，实际视图的输出中有多少列？（如果视图非常宽，则由于网络流量以及数据的客户端呈现，可能会对客户端性能产生负面影响。）

Answer 2

首先，让我们看看问题实际上是SQL Server、应用程序还是其他。打开SQL事件探查器并启动跟踪。

在跟踪运行的情况下，执行以下查询：

• SELECT TOP 5000a.app_id从dbo.app_table；（运行这一个SSMS）
• SELECT TOP 5000a.app_id从dbo.app_table；（在您的app/JDBC客户端中运行此项）

（为了彻底起见，您可以针对您的视图重复上面的SELECT语句。）

停止跟踪并记录各个应用程序的执行时间(持续时间)。