SQL Server Expresslocaldb等待操作超时-查询是否随机超时？

如何解决SQL Server Expresslocaldb等待操作超时-查询是否随机超时？

我有一个简单的SELECT查询，该查询返回的数据集比较大（11k行），并且在我的应用程序运行时随机超时。这是在使用localdb的我自己的开发笔记本电脑上发生的。当它工作时，它几乎立即返回数据，而其他时间-Microsoft.Data.SqlClient.SqlException: The wait operation timed out.。使用SSMS失败时，也会感觉很慢，但是它总是会完成查询。

SQL如下

(@CurrentUserId int)
-- First,select Draft issues created by current user
SELECT [I].[IssueId],[I].[IssueGuid],[I].[IssueNumber],[I].[DateCreated],[I].[DateOpened],[I].[DateLastModified],[I].[DateClosed],[I].[Title],[I].[Type],[I].[Status],[I].[CreatedByUserId],1 AS [OrderKey]
FROM [cm].[IssuesTbl] [I]
WHERE [I].[Status] = 0 AND [I].[CreatedByUserId] = @CurrentUserId

UNION ALL

-- Last,select Open issues
SELECT [I].[IssueId],2 AS [OrderKey]
FROM [cm].[IssuesTbl] [I]
WHERE [I].[Status] = 1

ORDER BY [OrderKey] ASC,[I].[DateOpened] DESC,[I].[DateCreated] DESC

执行计划为here.

我安装了Blitz，然后运行sp_BlitzFirst给我一些想法，但是我不确定要查找什么以及如何解决该问题。请帮忙。

@@版本：

Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64)   Oct 28 2016 18:17:30   Copyright (c) Microsoft Corporation  Express Edition (64-bit) on Windows 10 Enterprise 6.3 <X64> (Build 17134: )

sp_BlitzFirst：

10  Server Performance  Poison Wait Detected: RESOURCE_SEMAPHORE
For 4 seconds over the last 5 seconds,SQL Server was waiting on this particular bottleneck.

200 Wait Stats  RESOURCE_SEMAPHORE
For 4 seconds over the last 5 seconds,SQL Server was waiting on this particular bottleneck.

解决方法

似乎您有内存问题。您应该检查自己的状态：

SELECT 
  ((t1.requested_memory_kb)/1024.00) MemoryRequestedMB,CASE WHEN t1.grant_time IS NULL THEN 'Waiting' ELSE 'Granted' END AS RequestStatus,t1.timeout_sec SecondsToTerminate
FROM sys.dm_exec_query_memory_grants t1
  CROSS APPLY sys.dm_exec_sql_text(t1.sql_handle) t2

您不想等待。同样，您应该运行

SELECT total_physical_memory_kb,available_physical_memory_kb,total_page_file_kb,available_page_file_kb,system_memory_state_desc
FROM sys.dm_os_sys_memory WITH (NOLOCK) OPTION (RECOMPILE);

您想要的是Available physical memory is high。如果不这样做，则意味着内存有问题。然后的问题是，您是否有竞争的流程。

,

您可以尝试的几件事

• 查询计划在表上有两个完整的聚集索引扫描。鉴于您可能至少需要阅读一次（以获得“公开”问题），因此您最好使用单个SELECT而不是UNION。
  • 如果您可以使用索引进行查找并避免对整个表/群集进行索引扫描，那么UNION方法将非常有效。如果没有可以使用的索引，那么还可以限制读取数据的次数。
• 订购者吃掉了内存（订购需要占用大量CPU和内存）。是否可以通过ID而不是DateOpened来订购？
• 根据可用的状态以及每种状态有多少行，在[cm]。[IssuesTbl]。[Status]
上放置非聚集索引。

这是我建议的代码。我将顺序更改为以res.send开头，因为它已经按顺序排列了，但是我没有将第二个字段更改为ID-但可以的话，请执行此操作。

Status