主页 / dba / 问题 / 315036
Accepted
wmaciel
Asked: 2022-07-30 11:05:47 +0800 CST

为什么 SQL Server 查询会两次请求同一个锁并出现死锁？

  • 772

我有 SQL Server 数据库，当两个查询尝试获取它们已经拥有的同一个表的锁时，它会一直死锁。 死锁图 上面的死锁图让我很困惑。两个PageLock是相同的，这让我相信它们是同一个页面。这似乎表明两个进程都已经拥有对该页面的锁定。左边的那个拥有一个更新（U）锁，而右边的那个拥有一个意图排他（IX）锁。

这怎么可能呢？

为什么他们在获取他们已经拥有的锁时会被阻止？

左边进程的查询是： 左查询

右侧进程查询为： 正确查询

sql-server deadlock

1 个回答

  1. Best Answer

    理想情况下，我们需要查看完整的 XDL 图以及查询计划才能确定。请注意，页面锁并不相同，它们具有不同的页面 ID。

    但最有可能发生的事情如下：

    • 查询不太可能是罪魁祸首，因为它是一个没有连接的INSERT简单单行插入（尽管理论上可能索引视图或外键 Assert 可能导致死锁）
    • 该UPDATE查询可能没有支持索引。这将导致它扫描整个表，不必要地锁定大量行，并为死锁创造更多机会。
    • 死锁的实际原因将是UPDATE扫描表的顺序是一个顺序，但顺序INSERT是不同的。

    要解决这个问题，您需要添加一个索引来支持UPDATE. 最可能的索引可能如下，但请注意，我不知道您的表结构，也不知道其他查询正在发生什么，因此不同的索引可能会更好。

    CREATE INDEX IX ON InventoryTotals
  (SellerID, GlobalOfferID) INCLUDE (OfferStatus);

    这个特定索引的原因是更新查看单个SellerID值，但GlobalOfferID似乎是一个IN所以它可能是多个值。OfferStatus也需要在那里以避免键查找，但它不必是键列，它可以是INCLUDE.

    现在UPDATE将访问它需要的确切密钥，并仅在其上放置一个 U 型锁和一个 X 型锁，因此您现在应该避免死锁，因为访问将始终以正确的顺序进行。

    我注意到最后一件事：这两个语句似乎具有不同大小的varchar参数。这表明您依靠驱动程序来获取正确的数据类型和大小，例如使用 SqlClient 的AddWithValue. 永远不要这样做：始终为每个参数指定数据类型和长度/精度。

    • 2

相关问题