为使用完全相同的查询重复访问数据库的应用程序优化 SQL Server？

Question

我正在处理后端使用 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)

查询后面的数字是执行精确查询的次数，例如SELECT * FROM "Patient" WHERE "_Recno" = 35051，使用 _Recno执行查询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。虽然我不认为它有内存问题，但从外观来看，磁盘似乎是最大的硬件瓶颈。

Answer 1

查询相同不是问题，并且在某些方面有所帮助，因为执行计划已被缓存，并且查询所需的数据页仍应被缓存。那么问题往往是身份验证和初始化会话的每个连接的开销。

首先要检查的是：是否使用了“连接池”？您可以使用 SQL Server Profiler 对此进行测试，在“存储过程”类别中选择“RPC:Completed”事件，确保检查该事件的“TextData”、“ClientProcessID”和“SPID”（在至少，如果您愿意，您可以选择其他列）。然后，转到“列过滤器”，选择“TextData”，并在“喜欢”条件中添加以下条件：exec sp[_]reset[_]connection。现在运行该跟踪。如果您看到exec sp_reset_connection的实例通过，那么这是由于使用了连接池。但这并不一定意味着这个应用程序正在使用它。因此，请查看探查器跟踪中的“SPID”之一，并尝试将其与以下查询的输出进行匹配：

SELECT sssn.login_time,
       DATEDIFF(MILLISECOND, conn.connect_time, sssn.login_time)
                  AS [MillisecondsBetweenConnectionAndSessionStart],
       conn.*,
       sssn.[program_name],
       sssn.host_process_id,
       sssn.client_interface_name,
       sssn.login_name,
       qry.[text]
FROM sys.dm_exec_connections conn
INNER JOIN sys.dm_exec_sessions sssn
        ON sssn.session_id = conn.session_id
OUTER APPLY sys.dm_exec_sql_text(conn.most_recent_sql_handle) qry
WHERE conn.session_id <> conn.most_recent_session_id
OR    DATEDIFF(MILLISECOND, conn.connect_time, sssn.login_time) > 50
ORDER BY conn.connect_time;

最右侧/末端的字段包含最近执行的查询。这应该确认该会话是有问题的应用程序（通过它正在做什么）。

如果您找不到任何一般使用连接池的证据，或者至少用于此应用程序，则需要更新应用程序使用的连接字符串以启用连接池。

...在大多数情况下，客户端应用程序和 SQL Server 位于同一台计算机上，并且通过 RDP 访问客户端的多个实例。在少数情况下，客户端位于 LAN 上的另一台计算机上......

根据问题的上述信息，似乎有多个客户端正在连接，对吗？如果是这样，那么连接池虽然可能仍然是一个好主意并且很有帮助，但效果会较差，因为每个客户端都维护自己的连接池。这意味着，5 个实例（或任意数量）仍将创建 5 个独立的连接池，并且每个实例都会减少其各自应用程序的连接启动开销，但无法将开销减少到超出该范围/降低到单个共享连接）。另请记住，即使使用连接池，如果应用程序在尝试打开新连接之前未正确关闭其连接，您仍然会拥有来自应用程序的给定实例的多个连接/会话。

在这种情况下，并且在单个应用程序不使用连接池并且无法更新其连接字符串以使用连接池的情况下，那么，如果可能更新应用程序，那么实现将非常有帮助缓存层，例如 Redis 或 memcache（我相信 AWS 和 Azure 都提供基于云的缓存解决方案）。这些重复的命中通常可以被缓存并完全绕过 RDBMS（当然是在指定的时间内），这也是这些东西存在的很大一部分原因。

现在我刚刚了解了最近对该问题的评论，看来连接字符串和应用程序的任何部分很可能都无法修改。在这种情况下，除了可能检查与 SQL Server 在同一服务器上运行的应用程序建立的连接是否使用共享内存或 TCP/IP 进行连接以及是否是 TCP 之外，我们无能为力。 /IP 用于同服务器连接，然后检查 SQL Server 是否启用了共享内存协议，如果没有，则启用它。这不是一个有保证的改进，因为连接字符串可能强制协议为 TCP/IP（例如使用语法：）server=tcp:{something}，但仍然值得尝试，因为该语法可能不会被使用。

更新

_{来自对此答案的评论：}

[上面的查询]没有给我任何信息，但是查找sys.dm_exec_connections.connect_time有问题的应用程序需要几个小时到几天的时间。...在每种情况下...连接和会话启动之间的差异始终低于 50 毫秒（3 到 16 之间）

这可以很好地表明问题所在，或者至少是问题的很大一部分。如果连接是在几个小时到几天前建立的，并且会话随后立即开始，则该应用程序要么是一个桌面应用程序，它建立单个连接和会话，并对其执行所有查询（类似于 SSMS 查询选项卡的工作方式），要么应用程序代码错误地没有每次关闭连接对象，在这种情况下，您可能会看到大量并发连接，其中许多连接实际上已被放弃，但仍然占用内存（在 SQL Server Express 上，可能存在一个连接无论如何都要限制）。

尝试以下查询，改编自上面的原始查询：

SELECT conn.connect_time,
       sssn.login_time,
       CASE WHEN conn.last_read > conn.last_write THEN conn.last_read
            ELSE conn.last_write END AS [LastActivity],
       GETDATE() AS [Now],
       DATEDIFF(MILLISECOND, conn.connect_time, sssn.login_time)
                  AS [MillisecondsBetweenConnectionAndSessionStart],
       DATEDIFF(MILLISECOND, sssn.login_time, CASE WHEN conn.last_read > conn.last_write
                                               THEN conn.last_read ELSE conn.last_write END)
                  AS [MillisecondsBetweenSessionStartAndLastActivity],
       DATEDIFF(MILLISECOND, CASE WHEN conn.last_read > conn.last_write
                         THEN conn.last_read ELSE conn.last_write END, GETDATE())
                  AS [MillisecondsBetweenLastActivityAndNow],
       sssn.[program_name],
       sssn.host_process_id,
       sssn.client_interface_name,
       sssn.login_name,
       qry.[text],
       conn.*
FROM sys.dm_exec_connections conn
INNER JOIN sys.dm_exec_sessions sssn
        ON sssn.session_id = conn.session_id
OUTER APPLY sys.dm_exec_sql_text(conn.most_recent_sql_handle) qry
WHERE  sssn.is_user_process = 1
ORDER BY [MillisecondsBetweenLastActivityAndNow] DESC;

如果正在使用连接池，那么您将看到字段值较高MillisecondsBetweenConnectionAndSessionStart但字段值较低的MillisecondsBetweenSessionStartAndLastActivity行。原因是连接已建立并重新使用。每次重新使用连接时，都会login_time重置为最近的SqlConnection.Open事件，然后立即执行查询。

如果您有一个具有稳定连接的桌面应用程序（例如 SSMS），您将看到与连接池相反的行为：您将看到字段值较低MillisecondsBetweenConnectionAndSessionStart但字段值较高的行MillisecondsBetweenSessionStartAndLastActivity。原因是连接一旦建立就永远不会关闭，只是继续对其执行查询。

如果您有一个应用程序没有关闭其连接，但仍然打开新连接（由于错误或误解连接池的工作原理 - 无论是否启用池），那么您不仅会拥有很多行，但它们的字段值较低，MillisecondsBetweenConnectionAndSessionStart但字段值较高MillisecondsBetweenLastActivityAndNow。如果建立连接并使用一次，然后在SqlConnection.Open()调用之前调用SqlConnection.Close()或SqlConnection.Dispose()（Dispose()将调用，如果对象是在构造中创建的，Close()则将自动调用），则会发生这种情况。SqlConnectionusing()