首頁猿問在一個(gè)事務(wù)中插入和更新時(shí) Sql...

在一個(gè)事務(wù)中插入和更新時(shí) Sql server 死鎖

Java

動(dòng)漫人物 2022-06-23 16:55:19

我正在使用 Azure SQL + Java + Spring Boot 2。目前我正在嘗試了解死鎖發(fā)生的原因。在事務(wù)中，我正在對(duì)同一張表但不同的行進(jìn)行插入和更新。據(jù)我了解，SQL Server 默認(rèn)使用rowlock和read_committed隔離。這是死鎖的詳細(xì)信息：<deadlock> <victim-list> <victimProcess id="process2b8618644e8"/> </victim-list> <process-list> <process id="process2b8618644e8" taskpriority="0" logused="352" waitresource="KEY: 16:72057594043760640 (5f601e0257f1)" waittime="1321" ownerId="9246067" transactionname="implicit_transaction" lasttranstarted="2019-02-17T13:03:49.683" XDES="0x2b868778458" lockMode="U" schedulerid="2" kpid="288932" status="suspended" spid="118" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2019-02-17T13:03:49.793" lastbatchcompleted="2019-02-17T13:03:49.760" lastattention="1900-01-01T00:00:00.760" clientapp="Microsoft JDBC Driver for SQL Server" hostname="TZ-MacBook-Pro.local" hostpid="0" loginname="master" isolationlevel="read committed (2)" xactid="9246067" currentdb="16" currentdbname="test" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058"> <executionStack> <frame procname="unknown" queryhash="0x431f2517c2d3feb8" queryplanhash="0x3a793ad664472011" line="1" stmtstart="110" stmtend="238" sqlhandle="0x02000000060c530e608cef3b3e4e4712f48c40d2efd9b04d0000000000000000000000000000000000000000"> unknown </frame> <frame procname="unknown" queryhash="0x0000000000000000" queryplanhash="0x0000000000000000" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"> unknown </frame> </executionStack>此外，我在 id 列上使用了聚集索引，隨機(jī)操作順序沒有問題。此外，當(dāng)我只在事務(wù)中插入時(shí)，一切正常，沒有死鎖。如果我切換到 PostgreSql，則不會(huì)出現(xiàn)死鎖問題。那么，為什么我在 Azure SQL 中遇到了死鎖？

查看完整描述

1 回答

陪伴而非守候

TA貢獻(xiàn)1757條經(jīng)驗(yàn) 獲得超8個(gè)贊

死鎖的一個(gè)常見原因是需要查詢和索引調(diào)整的查詢觸及的數(shù)據(jù)多于必要的數(shù)據(jù)。

死鎖跟蹤顯示參數(shù)作為nvarchar(4000)數(shù)據(jù)類型傳遞。這可能會(huì)阻止有效使用列上的索引，varchar因?yàn)?code>nvarchar它的數(shù)據(jù)類型優(yōu)先級(jí)高于varchar. 當(dāng)從應(yīng)用程序數(shù)據(jù)類型推斷參數(shù)數(shù)據(jù)類型時(shí)，此問題尤其常見，因?yàn)樽址ǔＪ?Unicode，例如在 Java 和 .NET 語言中，導(dǎo)致nvarchar參數(shù)與基礎(chǔ)列數(shù)據(jù)類型無關(guān)。

解決方案是對(duì)字符串使用 varchar 參數(shù)而不是 nvarchar，除非基礎(chǔ)列是nvarchar. 如果您不在nvarchar數(shù)據(jù)庫中使用，請(qǐng)指定 JDBC 連接字符串參數(shù)sendStringParametersAsUnicode，如本答案中所述?；蛘撸膽?yīng)用程序代碼或框架配置以使用列的varchar參數(shù)類型varchar。

最佳實(shí)踐是確保參數(shù)與基礎(chǔ)數(shù)據(jù)庫列的類型相匹配。這將提高性能和并發(fā)性，并且還有其他好處。

反對(duì) 回復(fù) 2022-06-23