我正在处理后端使用 SQL Server Express (2014) 的 Windows 应用程序的性能问题。
我主要通过检查索引 SQL Server 端设法使它运行得更好，但是有一个特定的报告仍然运行得非常慢。
查看它在做什么，它似乎在应用程序中循环并SELECT *针对一个表查询出数千个非常简单的查询WHERE = Primary Key，因此在每种情况下只检索一条记录。当我说 IDENTICAL 时，我的意思是相同，它甚至没有改变主键来获得不同的东西，它显然每次需要时都要求从数据库中返回完全相同的记录，仅在少数情况下多达一百次秒。
这是一个示例报告，在服务器安静时运行大约需要 10-15 秒——查询运行了多少次我添加为评论：
SELECT * FROM "Patient" WHERE "_Recno" = 35051 -- (runs 106 times)
SELECT * FROM "Client" WHERE "_Recno" = 15607 -- (99 times)
SELECT * FROM "SpeciesEntry" WHERE "_Recno" = 180 -- (97)
SELECT * FROM "Table" WHERE "_Recno" = 9 -- (97)
SELECT * FROM "DefaultEntry" WHERE "_Recno" = 2615 -- (96)
SELECT * FROM "Table" WHERE "_Recno" = 34 -- (96)
SELECT * FROM "DefaultEntry" WHERE "_Recno" = 2562 -- (84)
SELECT * FROM "Table" WHERE "_Recno" = 33 -- (84)
SELECT * FROM "Treatment" WHERE "_Recno" = 1682 -- (33)
SELECT * FROM "Treatment" WHERE "_Recno" = 1819 -- (33)
SELECT * FROM "Treatment" WHERE "_Recno" = 927 -- (33)
SELECT * FROM "Treatment" WHERE "_Recno" = 934 -- (33)
SELECT * FROM "Treatment" WHERE "_Recno" = 935 -- (33)
SELECT * FROM "Treatment" WHERE "_Recno" = 940 -- (33)
SELECT * FROM "Treatment" WHERE "_Recno" = 942 -- (33)
SELECT * FROM "Treatment" WHERE "_Recno" = 944 -- (33)
SELECT * FROM "OptionWP" WHERE "_Recno" = 103 -- (3)
SELECT * FROM "OptionWP" WHERE "_Recno" = 54 -- (1)
SELECT * FROM "PatientEstimate" WHERE "_Recno" = 8928 -- (1)
SELECT * FROM "Phrase" WHERE "_Recno" = 9718 -- (1)
SELECT * FROM "Table" WHERE "_Recno" = 4 -- (1)
SELECT * FROM "BreedEntry" WHERE "_Recno" = 3283 -- (1)
查询后的数字是执行确切查询的次数，例如，使用 _RecnoSELECT * FROM "Patient" WHERE "_Recno" = 35051执行查询 106 次。实际上有 1,031 个查询正在执行以构建此报告（在本例中，它有所不同）- 以上 23 个左右是不同的查询。
现在上面的每个查询都运行得非常非常快，在每种情况下我们都在谈论几十微秒。事实上，如果将用于制作此报告的所有 1,031 个查询加起来，所有这些查询所用的总时间仅为 59,193 微秒，或仅 59 毫秒。
所以问题和延迟似乎是开销——尽管在此报告中只有大约 59 毫秒的实际数据库时间，但报告需要大约 10-15 秒才能为客户端运行，因为它来回处理超过 1,000 个查询。
请注意，在大多数情况下，客户端应用程序和 SQL Server 在同一台机器上，并且客户端的多个实例通过 RDP 访问。在少数情况下，客户端位于 LAN 上的另一台机器上，我认为那里的性能会更差。但在大多数情况下，您可以认为不应该存在网络问题，因为客户端应用程序和 SQL Server 都在同一个物理盒子上。
十秒甚至可以接受，问题是在繁忙的时间可能会增加到一分钟或更长时间。
关于如何处理优化这个的任何想法？如果它是一个我可以访问源代码的应用程序，显然我会用一个或几个使用连接的查询替换所有这些，但这不是一个选项，该应用程序是一个黑盒子——我所能做的就是从 SQL Server 端优化。
与客户交谈时，虽然无论他们是通过 RDP 还是远程客户端应用程序安装使用它，性能都很差，但远程客户端应用程序的性能要差得多，这对他们来说更像是一个问题。因此，任何有关我可以查看以提高那里的性能的建议，关于网络或其他方面的建议，将不胜感激。需要注意的一件事是，这个 SQL 2014 框现在已经虚拟化了，以前他们使用的是我认为是 2008 年或 2012 年，但它没有虚拟化——他们说这份报告那时更快。他们有其他原因希望将其虚拟化，将其从虚拟化中移除不是一种选择。
它使用 Windows 身份验证和（我很确定）TCP/IP 进行连接。我认为我无法改变这一点。据我所知，它并没有断开和重新建立连接，它似乎至少在使用连接池。
我在日常工作中使用 Hibernate，之前我遇到过这种情况，ORM 生成了数千个查询，而我通常的解决方案是查看代码中的获取策略（惰性加载与急切加载）或者实际上在报告的情况下，通常用 SQL 重写整个事情。在这种情况下，虽然软件就是它的本质，一个 Windows 可执行文件，对此我无能为力，但我只能解决 SQL 方面的问题。
我的理解是供应商不再支持这个特定版本，并且已经回到使用平面文件而不是 SQL 的版本。这对客户不起作用——他们将这个数据库与其他各种东西集成在一起。它是小众软件，就像大多数此类软件一样，它在后端技术上很糟糕，但具有小众用户需要的功能。无论如何，我无法更改软件，只能更改 SQL Server 上的内容。它无法使用，但我已经可以使用了，因此在这些限制范围内取得了进展。
没有任何阻塞或锁定，我已经检查过了。这实际上是我解决的主要性能问题，但在过去一个月左右的时间里，根本没有任何阻塞足够长的时间来记录。内存并不是真正的问题，因为 SQL Server Express 无论如何都限制为 1GB。虽然我不认为它有内存问题，但从它的角度来看，磁盘似乎是最大的硬件瓶颈。