8

我有两个非常简单的表，我们称它们为 [UserData1] 和 [UserData2]。他们都有 [UserId] 列作为主键。我正在对这两个表运行两种类型的查询。一个是返回特定用户的组合数据的 SELECT 语句：

SELECT <a subset of columns from both tables>
FROM [UserData1] ud1
    FULL OUTER JOIN [UserData2] ud2 ON ud1.[UserId] = ud2.[UserId]
WHERE
    ud1.[UserId] = @UserId OR ud2.[UserId] = @UserId

另一个是为特定用户更新两个表中的用户数据的事务：

BEGIN TRANSACTION

UPDATE [UserData1]
SET <new values>
WHERE [UserId] = @UserId

UPDATE [UserData2]
SET <new values>
WHERE [UserId] = @UserId

COMMIT TRANSACTION

这里的问题是在 SELECT 语句中获取共享表锁的顺序是不确定的，如果 SQL Server 决定在 [UserData1] 之前锁定 [UserData2]，这可能（并且实际上确实）导致典型的死锁情况。在这种情况下，避免死锁的最佳方法是什么？

将这些表合并为一个表，对吗？我希望这很容易。假设有理由将它们分开。

READ UNCOMMITTED / NOLOCK 提示？假设不能容忍脏读。

SNAPSHOT 隔离级别？这将解决问题，但我不确定所涉及的开销。

所以问题归结为：有没有办法保证在连接表上获得锁的顺序？

起初我以为这可以通过FORCE ORDER查询提示来实现，但后来我通过实验发现它并不一定强制执行锁定表的顺序。在这种特殊情况下，另一种解决方案是为每个表发出单独的 SELECT 查询，然后在应用程序层中组合两个单行记录集，但如果我需要为多个用户进行查询，我仍然希望得到所有产生一个记录集。

更新：

这是死锁跟踪的摘录：

   Deadlock encountered .... Printing deadlock information
   Wait-for graph

   Node:1
   KEY: 17:72057594039173120 (e21762ccf3dc) CleanCnt:3 Mode:X Flags: 0x1
    Grant List 1:
      Owner:0x00000020F75B0480 Mode: X        Flg:0x40 Ref:0 Life:02000000 SPID:72 ECID:0 XactLockInfo: 0x00000020EB13ED68
      SPID: 72 ECID: 0 Statement Type: UPDATE Line #: 1
      Input Buf: Language Event: (@UserId bigint,@DataColumn2 int)update
   Requested by: 
     ResType:LockOwner Stype:'OR'Xdes:0x00000020FC98DA40 Mode: S SPID:75 BatchID:0 ECID:0 TaskProxy:(0x00000020DAB38608) Value:0xf75abbc0 Cost:(0/0)

   Node:2
   KEY: 17:72057594039107584 (e21762ccf3dc) CleanCnt:9 Mode:S Flags: 0x1
    Grant List 1:
      Owner:0x00000020EEBFE580 Mode: S        Flg:0x40 Ref:1 Life:00000000 SPID:75 ECID:0 XactLockInfo: 0x00000020FC98DA80
      SPID: 75 ECID: 0 Statement Type: SELECT Line #: 1
      Input Buf: Language Event: (@UserId bigint)select [t].[UserId], t.[DataColumn2], t1.[DataColumn1]
   Requested by: 
     ResType:LockOwner Stype:'OR'Xdes:0x00000020EB13ED28 Mode: X SPID:72 BatchID:0 ECID:0 TaskProxy:(0x0000001F671C6608) Value:0xf75b5400 Cost:(0/456)

   Victim Resource Owner:
    ResType:LockOwner Stype:'OR'Xdes:0x00000020FC98DA40 Mode: S SPID:75 BatchID:0 ECID:0 TaskProxy:(0x00000020DAB38608) Value:0xf75abbc0 Cost:(0/0)
  deadlock-list
   deadlock victim=process20fda2ccf8
    process-list
     process id=process20fda2ccf8 taskpriority=0 logused=0 waitresource=KEY: 17:72057594039173120 (e21762ccf3dc) waittime=4526 ownerId=3416711 transactionname=SELECT lasttranstarted=2013-07-11T18:42:20.943 XDES=0x20fc98da40 lockMode=S schedulerid=20 kpid=2800 status=suspended spid=75 sbid=0 ecid=0 priority=0 trancount=0 lastbatchstarted=2013-07-11T18:42:20.950 lastbatchcompleted=2013-07-11T18:42:20.950 lastattention=1900-01-01T00:00:00.950 clientapp=.Net SqlClient Data Provider hostname=hostname hostpid=27716 loginname=loginname isolationlevel=read committed (2) xactid=3416711 currentdb=17 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
      executionStack
       frame procname=adhoc line=1 stmtstart=36 sqlhandle=0x020000001fcbbe1423a0c65cc8411344c6040e879195af3a0000000000000000000000000000000000000000
  select [t].[UserId], t.[DataColumn2], t1.[DataColumn1] from [UserData1] t1 full outer join [UserData2] t on t1.[UserId]=t.[UserId] where t.[UserId]=@UserId or t1.[UserId]=@UserId option (force order)     
       frame procname=unknown line=1 sqlhandle=0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  unknown     
      inputbuf
  (@UserId bigint)select [t].[UserId], t.[DataColumn2], t1.[DataColumn1] from [UserData1] t1 full outer join [UserData2] t on t1.[UserId]=t.[UserId] where t.[UserId]=@UserId or t1.[UserId]=@UserId option (force order)    
     process id=process20fd055498 taskpriority=0 logused=456 waitresource=KEY: 17:72057594039107584 (e21762ccf3dc) waittime=4525 ownerId=3416764 transactionname=user_transaction lasttranstarted=2013-07-11T18:42:20.960 XDES=0x20eb13ed28 lockMode=X schedulerid=9 kpid=6024 status=suspended spid=72 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2013-07-11T18:42:20.970 lastbatchcompleted=2013-07-11T18:42:20.970 lastattention=1900-01-01T00:00:00.970 clientapp=.Net SqlClient Data Provider hostname=hostname hostpid=27716 loginname=loginname isolationlevel=read committed (2) xactid=3416764 currentdb=17 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
      executionStack
       frame procname=adhoc line=1 stmtstart=508 sqlhandle=0x02000000c0d74a32597ec460559a2d5dbdc92f7746cdce270000000000000000000000000000000000000000
  update UserData2 set [LastModified]=getutcdate(), [DataColumn2]=[DataColumn2]+@DataColumn2Increment where [UserId]=@UserId     
       frame procname=unknown line=1 sqlhandle=0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  unknown     
      inputbuf
  (@UserId bigint,@DataColumn2Increment int)update UserData2 set [LastModified]=getutcdate(), [DataColumn2]=[DataColumn2]+@DataColumn2Increment where [UserId]=@UserId    
    resource-list
     keylock hobtid=72057594039173120 dbid=17 objectname=database_name.dbo.UserData1 indexname=1 id=lock20ec75b380 mode=X associatedObjectId=72057594039173120
      owner-list
       owner id=process20fd055498 mode=X
      waiter-list
       waiter id=process20fda2ccf8 mode=S requestType=wait
     keylock hobtid=72057594039107584 dbid=17 objectname=database_name.dbo.UserData2 indexname=1 id=lock20ec07f600 mode=S associatedObjectId=72057594039107584
      owner-list
       owner id=process20fda2ccf8 mode=S
      waiter-list
       waiter id=process20fd055498 mode=X requestType=wait

显然，运行 SELECT 语句的进程在 [UserData1] 之前获得了对 [UserData2] 表的锁定，尽管 FORCE ORDER 提示。

4

2 回答 2

1

READ COMMITTED选择不应该参与死锁，因为它一次只能获取一个锁。读取锁定的行后可以立即释放锁。

我强烈建议您打开快照隔离。它将解决问题。熟悉所涉及的 3 个开销：增加的行大小、tempdb 写入和微小的读取开销。大多数时候它们没有意义。

于 2013-07-12T18:57:27.620 回答
0

首先（我认为）是第一个查询中的 where 子句是多余的。您在 Join 中拥有相同的东西，并且在 join 中更好，因为您正在执行完整的外部联接。

在避免死锁方面，它可能与第一个查询在删除读锁方面的处理方式有关。如果应用程序只是读取数据并且这不是用户事务的一部分，那么一旦读取完成，第二个查询将能够完成并且您不会遇到死锁。

您是在环境中遇到死锁，还是只是猜测您会遇到死锁。如果您发布死锁图，我们可以看到实际的锁是什么。

于 2013-07-12T17:39:49.687 回答