數(shù)據(jù)庫(kù)中死鎖是什么產(chǎn)生的？數(shù)據(jù)庫(kù)操作的死鎖是不可避免的，本文并不打算討論死鎖如何產(chǎn)生，重點(diǎn)在于解決死鎖，通過(guò)SQL Server 2005， 現(xiàn)在似乎有了一種新的解決辦法。 將下面的SQL語(yǔ)句放在兩個(gè)

數(shù)據(jù)庫(kù)中死鎖是什么產(chǎn)生的？

數(shù)據(jù)庫(kù)操作的死鎖是不可避免的，本文并不打算討論死鎖如何產(chǎn)生，重點(diǎn)在于解決死鎖，通過(guò)SQL Server 2005， 現(xiàn)在似乎有了一種新的解決辦法。 將下面的SQL語(yǔ)句放在兩個(gè)不同的連接里面，并且在5秒內(nèi)同時(shí)執(zhí)行，將會(huì)發(fā)生死鎖。 use Northwindbegin tran　　insert into Orders(CustomerId) values(@#ALFKI@#)　　waitfor delay @#00:00:05@#　　select * from Orders where CustomerId = @#ALFKI@#commitprint @#end tran@# SQL Server對(duì)付死鎖的辦法是犧牲掉其中的一個(gè)，拋出異常，并且回滾事務(wù)。在SQL Server 2000，語(yǔ)句一旦發(fā)生異常，T-SQL將不會(huì)繼續(xù)運(yùn)行，上面被犧牲的連接中， print @#end tran@#語(yǔ)句將不會(huì)被運(yùn)行，所以我們很難在SQL Server 2000的T-SQL中對(duì)死鎖進(jìn)行進(jìn)一步的處理。 現(xiàn)在不同了，SQL Server 2005可以在T-SQL中對(duì)異常進(jìn)行捕獲，這樣就給我們提供了一條處理死鎖的途徑： 下面利用的try ... catch來(lái)解決死鎖。 SET XACT_ABORT ONdeclare @r intset @r = 1while @r 0begin　　declare @ErrorMessage nvarchar(4000)　　declare @ErrorSeverity int　　declare @ErrorState int　　select　　　　@ErrorMessage = ERROR_MESSAGE()，　　　　@ErrorSeverity = ERROR_SEVERITY()，　　　　@ErrorState = ERROR_STATE()　　raiserror (@ErrorMessage，　　　　　　　 @ErrorSeverity，　　　　　　　 @ErrorState　　　　　　　 )end

mysql死鎖出現(xiàn)的原因？

MySQL有三種鎖的級(jí)別：頁(yè)級(jí)、表級(jí)、行級(jí)。

表級(jí)鎖：開(kāi)銷小，加鎖快；不會(huì)出現(xiàn)死鎖；鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低。

行級(jí)鎖：開(kāi)銷大，加鎖慢；會(huì)出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度也最高。

頁(yè)面鎖：開(kāi)銷和加鎖時(shí)間界于表鎖和行鎖之間；會(huì)出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般

所謂死鎖<DeadLock>：是指兩個(gè)或兩個(gè)以上的進(jìn)程在執(zhí)行過(guò)程中，因爭(zhēng)奪資源而造成的一種互相等待的現(xiàn)象，若無(wú)外力作用，它們都將無(wú)法推進(jìn)下去.此時(shí)稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖，這些永遠(yuǎn)在互相等待的進(jìn)程稱為死鎖進(jìn)程。表級(jí)鎖不會(huì)產(chǎn)生死鎖.所以解決死鎖主要還是針對(duì)于最常用的InnoDB。

死鎖的關(guān)鍵在于：兩個(gè)(或以上)的Session加鎖的順序不一致。

那么對(duì)應(yīng)的解決死鎖問(wèn)題的關(guān)鍵就是：讓不同的session加鎖有次序

數(shù)據(jù)庫(kù)表死鎖是如何造成的？如何避免（解決）死鎖？

具體是什么情況？是不是有兩條一樣的記錄？如果是，那說(shuō)明你表沒(méi)主鍵，要設(shè)置一列為主鍵就行了。當(dāng)然，必須先清表。

數(shù)據(jù)庫(kù)表死鎖是如何造成的?如何避免(解決)死鎖？

在數(shù)據(jù)庫(kù)的用戶看來(lái)，事務(wù)是并發(fā)的，可以同時(shí)發(fā)生。可從數(shù)據(jù)庫(kù)內(nèi)部看來(lái)，為了實(shí)現(xiàn)隔離性，事務(wù)在概念上都是有先后順序的。這個(gè)順序，只是針對(duì)于事務(wù)有沖突（沖突包括1.讀和寫(xiě) 2.寫(xiě)和寫(xiě)）的情形來(lái)說(shuō)的；若無(wú)沖突，順序無(wú)關(guān)緊要。死鎖發(fā)生時(shí)，就是違反這個(gè)先后順序規(guī)則的時(shí)候。鎖定的目的，就是為了確保數(shù)據(jù)庫(kù)不會(huì)發(fā)生不可串行化異常。 從A轉(zhuǎn)賬到B，就是寫(xiě)A和B。 兩個(gè)事務(wù) T1， T2 T1 write A write B T2 write B write A T1，T2并發(fā)， 如果調(diào)度的序列是這樣的： T1 write A， T2 write B， T1 write B， T2 write A T1認(rèn)為在T1應(yīng)在T2之前，而T2認(rèn)為T(mén)2應(yīng)在T1之前，死鎖了，違反鎖定繼續(xù)下去就不可串行化了。 如果調(diào)度的序列產(chǎn)生一個(gè)可串行化的調(diào)度(有與之等價(jià)串行調(diào)度，在語(yǔ)義上等價(jià)于T1在T2前，或T2在T1前)，那么就不會(huì)發(fā)生死鎖。 --------------------回答題主的問(wèn)題 1.只要在事務(wù)中，就沒(méi)問(wèn)題 2.可能會(huì)死鎖 3.如果發(fā)生了死鎖，MySQL死鎖檢測(cè)會(huì)檢測(cè)到，回滾事務(wù)。避免死鎖（理論上應(yīng)該叫死鎖預(yù)防 （Deadlock Prevention），死鎖避免（Deadlock Avoidance）通過(guò)一些算法，如銀行家算法，動(dòng)態(tài)的去檢測(cè)加鎖請(qǐng)求是否會(huì)產(chǎn)生死鎖危險(xiǎn)，很難應(yīng)用在數(shù)據(jù)庫(kù)用戶層上），只要打破死鎖發(fā)生的條件(死鎖的四個(gè)條件)即可。數(shù)據(jù)庫(kù)用戶層面可做的，一般是破壞環(huán)路條件，按順序加鎖就不會(huì)產(chǎn)生環(huán)。拿這個(gè)例子來(lái)說(shuō)，不管是從A轉(zhuǎn)到B，還是從B轉(zhuǎn)到A，我們都先寫(xiě)A，后寫(xiě)B(tài)就可以避免死鎖。

那些面試了一小時(shí)以上又不給offer的面試官是怎么想的？

招人是幌子，套經(jīng)驗(yàn)才是目的，除非是真想發(fā)offer