select查询中mssql中的索引意外锁定

我一直在

Caused by: java.sql.SQLException: Transaction (Process ID 61) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

因此，我使用

DBCC TRACEON(1222,-1)
DBCC TRACEON(1204,-1)

日志中会打印以下死锁信息：

这些行表示已检测到死锁，进程1已被选为牺牲品

process-list
deadlock victim=PROCESS_ID_1
deadlock-list

---

进程id的日志\u 1

   [1] (@P0 nvarchar(4000))select namesequen0_.id as id1_47_<c/> namesequen0_.container_id as containe9_47_<c/> namesequen0_.increment_ as incremen2_47_<c/> namesequen0_.nextValue as nextValu3_47_<c/> namesequen0_.numChars as numChars4_47_<c/> namesequen0_.padChar as padChar5_47_<c/> namesequen0_.scope as scope6_47_<c/> namesequen0_.sequenceType as sequence7_47_<c/> namesequen0_.uppercase as uppercas8_47_ from NameSequence namesequen0_ where (namesequen0_.scope like  @P0 ) and (namesequen0_.container_id is null)        
    [2] frame procname=adhoc line=1 stmtstart=40 sqlhandle=0x020000005734e00acfb3060d49cc0e8565acb3b105807744
    [3] executionStack
    [4] process id=PROCESS_ID_1 taskpriority=0 logused=1248 waitresource=KEY: 14:72057594053459968 (95c9fddfaf17) waittime=3506 ownerId=13645568 transactionname=implicit_transaction lasttranstarted=2015-06-02T07:52:41.660 XDES=0xa30dd950 lockMode=S schedulerid=1 kpid=1848 status=suspended spid=68 sbid=0 ecid=0 priority=0 trancount=1 lastbatchstarted=2015-06-02T07:52:41.663 lastbatchcompleted=2015-06-02T07:52:41.660 clientapp=jTDS hostname=QALAB6 hostpid=123 loginname=qalab6_nrm isolationlevel=read committed (2) xactid=13645568 currentdb=14 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128058

这就意味着

[1] 资源

qalab6\u nrm.dbo.namesequence indexname=namesequence\u PK

被

process\u id\u 2

以独占锁定模式锁定，并且

process\u id\u 1

正在等待它

[2] 资源

qalab6_nrm.dbo.vfditem indexname=vfditem_pk

由

process_id_1

以独占锁定模式锁定，并且

process_id_2

正在等待它

---

宾果游戏我们可以看到它是如何陷入僵局的

---

现在是奇怪的部分

如果我们仔细看一下，

process\u id\u 1

正试图从表名

NameSequence

和列

NameSequence运行select查询。container\u id

是表

vfditem

的外键，

process\u id\u 1

已获得vfditem表的

indexname=vfditem\u pk上的锁

[1]为什么
process\u is\u 1
会锁定vfditem的索引？

此外，
process\u id\u 2
正在尝试从表名
vfditem
和列
vfditem运行select查询。namesequence\u id
是表
namesequence
中的外键，
process\u id\u 2
已经获得了namesequence表的
indexname=namesequence\u PK

[2]为什么
process\u is\u 2
会在名称序列的索引上获取锁？MSSQL在select语句上使用锁，它可以执行表、页和行锁。这实际上取决于您希望在系统中执行的操作，以及更重要的操作，但在此过程中，一个好的指针是查看可以放在SELECT语句上的操作，特别是查看
NOWAIT
、
NOLOCK
、
READCOMMITTED
和
READ\u COMMITTED\u SNAPSHOT

您可能还想考虑在其他地方设置所有事务以避免此问题。
这是一些非常基本的信息，DBA可能能够提供更详细的答案，但这些选项将阻止该问题的发生

您可以通过运行
DBCC useroptions
来判断隔离级别，也可以通过从sys.databases运行
SELECT is\u read\u committed\u snapshot\u on来判断read\u committed\u snapshot\u快照，其中name='YourDatabase'
MSSQL在SELECT语句上使用锁定，它可以执行表、页和行锁定。这实际上取决于您希望在系统中执行的操作，以及更重要的操作，但在此过程中，一个好的指针是查看可以放在SELECT语句上的操作，特别是查看
NOWAIT
、
NOLOCK
、
READCOMMITTED
和
READ\u COMMITTED\u SNAPSHOT

您可能还想考虑在其他地方设置所有事务以避免此问题。
这是一些非常基本的信息，DBA可能能够提供更详细的答案，但这些选项将阻止该问题的发生

您可以通过运行
DBCC useroptions
来判断您的隔离级别，也可以通过从sys.databases WHERE name='YourDatabase'

运行

SELECT is\u read\u committed\u snapshot\u on来判断read\u committed\u snapshot\u是否正确。。。但是为什么选择两个不同表的查询会锁定彼此的索引呢？DBA可以向您提供更多关于这一切原因的信息，但基本上它会锁定数据的行和页，根据您所说的，可能有两个查询相互阻止从表中的同一数据段中进行选择。当我们遇到此问题时，一个查询锁定了一个页面，另一个查询在一行上执行索引查找。尽管根本的问题仍然是一样的，它试图同时选择相同的信息，但它会死锁。通过更改隔离级别或在数据库上使用
READ\u COMMITTED\u SNAPSHOT
标志，这应该是一个简单的修复方法。如果包含这两个查询和表定义，它应该会详细说明原因。如果您查看这些日志，您可能还会看到，对于这些进程中的每一个，都应该有一个页面或行锁。但很有可能这并不容易重现。查询已经包含在日志中，我已经描述了哪个列是外来的，哪个表是好的。。。但是为什么选择两个不同表的查询会锁定彼此的索引呢？DBA可以向您提供更多关于这一切原因的信息，但基本上它会锁定数据的行和页，根据您所说的，可能有两个查询相互阻止从表中的同一数据段中进行选择。当我们遇到此问题时，一个查询锁定了一个页面，另一个查询在一行上执行索引查找。尽管根本的问题仍然是一样的，它试图同时选择相同的信息，但它会死锁。通过更改隔离级别或在数据库上使用
READ\u COMMITTED\u SNAPSHOT
标志，这应该是一个简单的修复方法。如果包含这两个查询和表定义，它应该会详细说明原因。如果您查看这些日志，您可能还会看到，对于这些进程中的每一个，都应该有一个页面或行锁。但很有可能这并不容易重现。查询已经包含在日志中，我已经描述了哪个列是外来的，哪个表是好的。。。但是为什么两个不同表的select查询会锁定彼此的索引呢
[1]select card0_.id as id2_77_<c/> card0_.autoDisplayName as autoDisp3_77_<c/> card0_.autoPartialName as autoPart4_77_<c/> card0_.namedWithSequence_id as namedWi38_77_<c/> card0_.namedWithSequenceValue as namedWit5_77_<c/> card0_.userDisplayName as userDisp6_77_<c/> card0_.userPartialName as userPart7_77_<c/> card0_.lifeCycleState_id as lifeCyc40_77_<c/> card0_.model_id as model41_77_<c/> card0_.outOfService as outOfSe12_77_<c/> card0_.bottomClearance as bottomC13_77_<c/> card0_.leftClearance as leftCle14_77_<c/> card0_.rightClearance as rightCl15_77_<c/> card0_.topClearance as topClea16_77_<c/> card0_.ncmElementKey as ncmElem24_77_ from VfdItem card0_ where card0_.DTYPE='Card' and card0_.ncmElementKey= @P0
[2]frame procname=adhoc line=1 stmtstart=40 sqlhandle=0x02000000386ba721896ce39b0b7c9d01df11539c0d843c83
[3]executionStack
[4]process id=PROCESS_ID_2 taskpriority=0 logused=62048 waitresource=KEY: 14:72057594051297280 (fadae9b0c9d3) waittime=3333 ownerId=13645330 transactionname=implicit_transaction lasttranstarted=2015-06-02T07:52:39.570 XDES=0xbf9f5950 lockMode=S schedulerid=1 kpid=5344 status=suspended spid=66 sbid=0 ecid=0 priority=0 trancount=1 lastbatchstarted=2015-06-02T07:52:41.833 lastbatchcompleted=2015-06-02T07:52:41.813 clientapp=jTDS hostname=QALAB6 hostpid=123 loginname=qalab6_nrm isolationlevel=read committed (2) xactid=13645330 currentdb=14 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128058

[11] waiter id=PROCESS_ID_2 mode=S requestType=wait
[10] waiter-list
[9] owner id=PROCESS_ID_1 mode=X
[8] owner-list
[7] keylock hobtid=72057594051297280 dbid=14 objectname=qalab6_nrm.dbo.vfditem indexname=vfditem_pk id=lock85330d00 mode=X associatedObjectId=72057594051297280
[6] waiter id=PROCESS_ID_1 mode=S requestType=wait
[5] waiter-list
[4] owner id=PROCESS_ID_2 mode=X
[3] owner-list
[2] keylock hobtid=72057594053459968 dbid=14 objectname=qalab6_nrm.dbo.namesequence indexname=NameSequence_PK id=lock848c3380 mode=X associatedObjectId=72057594053459968
[1] resource-list