在我正在开发的一个网络应用程序中，有一个UPDATE正在减慢/阻止其他几个查询：
UPDATE products
SET visible = 1
WHERE merchant_id = in_merchant_id
AND source_code IN (
SELECT source_code
FROM feeds_processing_data
WHERE processing_id = in_processing_id
)
它基本上更新了桌子上的特定“窗口” products，根据其他一些信息打开或关闭可见性。该表是 Web 应用程序的核心，来自前端的搜索在其中运行（通过全文或通过代码查找），后台进程会不时更新其内容。
我通常通过检查查询计划并验证是否存在正确的索引来解决这些问题。
然而，令我困惑的是，列出的会话information_schema.PROCESSLIST显示上述查询位于该preparing状态，而其他被阻止的查询是Waiting for table flush，我对此知之甚少或一无所知。
这是被阻止的查询之一：
SELECT id,
[...]
FROM (
SELECT (MATCH(NAME, description, manufacturer_name) AGAINST('+crema +mani' IN BOOLEAN MODE)) AS rank,
p.*
FROM products p
WHERE visible = 1
AND MATCH(NAME, description, manufacturer_name) AGAINST('+crema +mani' IN BOOLEAN MODE) LIMIT 400
) ranked …我和我的团队有一个问题，我们需要能够识别阻塞其他进程并杀死它们的进程。有大量脚本可免费用于执行这些操作。我们尝试了各种方法并仔细检查了代码。（如果您是发布了这些查询之一的人，谢谢！）
在我进一步讨论之前，让我告诉您这是针对我们无法修改的供应商应用程序。供应商也不愿意花时间找出进程被阻塞的原因。此时我们唯一的选择是终止长时间运行的进程（如供应商支持所建议的那样）。在终止这些进程之前，我们确实检查了正在运行的查询，但在 99.9% 的情况下，它显示为FETCH API_CURSOR00000000000A7E1F，这告诉我们什么都没有。
到目前为止，这一直是一个手动过程。现在，我们希望自动杀死这些长时间运行的阻塞进程，而不是有人手动杀死它们。
我们想在将它投入生产之前测试这个脚本。我们需要一些帮助来创建一个有意创建阻塞进程的脚本。我们已经尝试在 TEST 环境中使用此应用程序，但不幸的是，我们没有成功复制阻塞进程。
提前感谢你的帮助！
当我sys.sysprocesses在 SQL 2008R2 中签入时，存在许多阻塞会话。其中大部分是插入、更新和删除语句，具有与锁相关的等待类型。
这会导致超时问题吗？谁能确认这是否会导致超时/性能问题？
我将获得一个由 SQL Server 数据库在运行时分配的 GUID 列表。
我的直接想法是为 GUID 创建一个表。当一批 GUID 被订购时，它们将被插入到表中。
然后，在运行时，将调用 SPROC 从表中选择 GUID。我可以检索下一个 GUID 并立即将其从表中删除，或者检索下一个 GUID 并更新另一列以声明其已使用。
但这让我想知道同时对数据库进行两次调用以获取 GUID 的竞争条件的可能性。在我看来，如果时间完全不方便的话，可以为这两个调用检索相同的 GUID。
Q1：我对这种潜在竞争状况的担忧是否正确？即它会发生吗？
Q2：有没有办法避免这种情况（例如设置一个 SPROC 以在每次调用时阻塞？）
我能想到的一种至少可以使竞争条件失败的方法是设置另一个进行 GUID 分配的表，并将 GUID 列设置为唯一。然后，在运行时过程中，当检索到 GUID 时，它将通过 GUID 分配表分配给产品。如果为两个产品颁发了相同的 GUID，那么当需要分配它们时，其中一个产品将无法分配并被拒绝。
我试图理解为什么 SQL Server (2014) 在死锁场景中放置独占键锁。我已将整个死锁图粘贴在下面。
我很困惑，因为死锁发生在两个 SELECT 语句之间，两者都作为单个 READ COMMITTED 语句运行，而不是在事务内运行（因此同一事务中的其他地方没有发生更新等）。
我相信发生死锁是因为每个进程都在索引上创建一系列键锁，并且由于获取它们的顺序，所以发生了死锁。但是，如果进程仅创建共享锁，则不应出现死锁（根据我的理解）！
所以根本问题是 - 为什么这些 SELECT 语句会获取独占键锁？
我希望这只是我对锁定的误解。任何建议将不胜感激。
<deadlock>
<victim-list>
<victimProcess id="processd7f647848" />
</victim-list>
<process-list>
<process id="processd7f647848" taskpriority="0" logused="25948" waitresource="KEY: 32:72057594051428352 (e2d15ad895e9)" waittime="5014" ownerId="394724294049" transactionname="user_transaction" lasttranstarted="2022-04-06T09:46:18.770" XDES="0x67bf873350" lockMode="S" schedulerid="15" kpid="26196" status="suspended" spid="306" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2022-04-06T09:46:18.783" lastbatchcompleted="2022-04-06T09:46:18.783" lastattention="1900-01-01T00:00:00.783" clientapp=".Net SqlClient Data Provider" hostname="myhost" hostpid="1500" loginname="myuser" isolationlevel="read committed (2)" xactid="394724294049" currentdb="32" lockTimeout="4294967295" clientoption1="673185824" clientoption2="128056">
<executionStack>
<frame procname="MyDatabase.Main.GetMessages" line="154" stmtstart="11934" stmtend="12156" sqlhandle="0x03002000ebd98264d1bfae0066ae000001000000000000000000000000000000000000000000000000000000">
SELECT ID, Message FROM [dbo].[Messages] WHERE MessageType = @Type …我知道这是一个笼统的问题，但我必须澄清一些基本问题。
我知道当对 SQL Server 数据库表进行写入时，对该表的读取将不得不等待。
我的问题是：我正在使用的 SQL 数据库服务器暴露于多次写入和少量读取。一些 SSRS 报告也在同一台服务器上运行。
我知道最好从同一数据库的重复实例执行报告。但是对于一些报表，是否值得设置一个重复的实例进行报表？
有时我会抱怨某些报告运行缓慢。