關(guān)系型數(shù)據(jù)庫(kù)，如SQL Server，使用鎖來(lái)避免多用戶修改數(shù)據(jù)時(shí)的并發(fā)沖突。當(dāng)一組數(shù)據(jù)被某個(gè)用戶鎖定時(shí)，除非第一個(gè)用戶結(jié)束修改并釋放鎖，否則其他用戶就無(wú)法修改該組數(shù)據(jù)。
有些數(shù)據(jù)庫(kù)，包括SQL Server，用鎖來(lái)避免用戶檢索未遞交的修改記錄。在這些系統(tǒng)中，如果用戶A在修改一組記錄，則其他用戶只有等用戶A修改完畢了，才能檢索。
數(shù)據(jù)庫(kù)在每個(gè)物理層上設(shè)置鎖：記錄行(rows)，數(shù)據(jù)頁(yè)(pages, 上百萬(wàn)記錄行)，擴(kuò)展頁(yè)(extends, 多個(gè)數(shù)據(jù)頁(yè))，整個(gè)表，甚至整個(gè)數(shù)據(jù)庫(kù)。有些數(shù)據(jù)庫(kù)(如Oracle等)只使用精細(xì)的行鎖機(jī)制，而別的數(shù)據(jù)庫(kù)，則使用在頁(yè)面，擴(kuò)展頁(yè)，表和數(shù)據(jù)庫(kù)上的較大范圍的鎖機(jī)制。大多數(shù)數(shù)據(jù)庫(kù)，包括SQL Server，同樣支持行鎖機(jī)制，但是經(jīng)常使用的還是大范圍鎖機(jī)制。 這主要是因?yàn)楣芾礞i需要付出高昂的代價(jià)。鎖十分復(fù)雜而且數(shù)量很多，所以如果全都是 行鎖的話，將是極為痛苦的：一百萬(wàn)行的數(shù)據(jù)更新就會(huì)輕易消耗巨大的內(nèi)存，從而根本無(wú)法進(jìn)行管理。
鎖爭(zhēng)用的描述
那些不僅僅使用行級(jí)鎖的數(shù)據(jù)庫(kù)使用一種稱為混和鎖(lock escalation)的技術(shù)來(lái)獲取較高的性能。除非很明確知道是針對(duì)整個(gè)數(shù)據(jù)表，否則這些數(shù)據(jù)庫(kù)的做法是開始使用行級(jí)鎖， 然后隨著修改的數(shù)據(jù)增多，開始使用大范圍的鎖機(jī)制。
不幸的是，這種混和鎖的方法會(huì)產(chǎn)生和放大新的問(wèn)題：死鎖。如果兩個(gè)用戶以相反的順序修改位于不同表的記錄，而這兩條記錄雖然邏輯上不相關(guān)， 但是物理上是相鄰的，操作就會(huì)先引發(fā)行鎖，然后升級(jí)為頁(yè)面鎖。這樣， 兩個(gè)用戶都需要對(duì)方鎖定的東西，就造成了死鎖。
例如：
用戶A修改表A的一些記錄，引發(fā)的頁(yè)面鎖不光鎖定正在修改的記錄，還會(huì)有很多其它記錄也會(huì)被鎖定。
用戶B修改表B的一些記錄，引發(fā)的頁(yè)面鎖鎖定用戶A和其它正在修改的數(shù)據(jù)。
用戶A想修改用戶B在表B中鎖定(并不一定正在修改的)數(shù)據(jù)。
用戶B想修改或者僅僅想訪問(wèn)用戶A在表A中鎖定(并不一定正在修改)的數(shù)據(jù)。
為了解決該問(wèn)題，數(shù)據(jù)庫(kù)會(huì)經(jīng)常去檢測(cè)是否有死鎖存在，如果有，就把其中的一個(gè)事務(wù)撤銷，好讓另一個(gè)事務(wù)能順利完成。一般來(lái)說(shuō)，都是撤銷 那個(gè)修改數(shù)據(jù)量少的事務(wù)，這樣回滾的開銷就比較少。使用行級(jí)鎖的數(shù)據(jù)庫(kù) 很少會(huì)有這個(gè)問(wèn)題，因?yàn)閮蓚€(gè)用戶同時(shí)修改同一條記錄的可能性極小，而且由于極其偶然的修改數(shù)據(jù)的順序而造成的鎖也少。
而且，數(shù)據(jù)庫(kù)使用鎖超時(shí)來(lái)避免讓用戶等待時(shí)間過(guò)長(zhǎng)。查詢超時(shí)的引入也是為了同樣目的。我們可以重新遞交那些超時(shí)的查詢，但是這只會(huì)造成數(shù)據(jù)庫(kù) 的堵塞。如果經(jīng)常發(fā)生超時(shí)，說(shuō)明用戶使用SQL Server的方式有問(wèn)題。正常 情況是很少會(huì)發(fā)生超時(shí)的。
在服務(wù)器負(fù)載較高的運(yùn)行環(huán)境下，使用混合鎖的SQL Server鎖機(jī)制，表現(xiàn)不會(huì)很好。 原因是鎖爭(zhēng)用(Lock Contention)。鎖爭(zhēng)用造成死鎖和鎖等待問(wèn)題。在一個(gè)多用戶系統(tǒng)中，很多用戶會(huì)同時(shí)在修改數(shù)據(jù)庫(kù)，還有更多的用戶在同時(shí)訪問(wèn)數(shù)據(jù)庫(kù)，隨時(shí)會(huì)產(chǎn)生鎖，用戶 也爭(zhēng)先恐后地獲取鎖以確保自己的操作的正確性，死鎖頻繁發(fā)生，這種情形下， 用戶的心情可想而知。
確實(shí)，如果只有少量用戶，SQL Server不會(huì)遇到多少麻煩。內(nèi)部測(cè)試和發(fā)布的時(shí)候，由于用戶較少， 也很難發(fā)現(xiàn)那些并發(fā)問(wèn)題。但是當(dāng)激發(fā)幾百個(gè)并發(fā)，進(jìn)行持續(xù)不斷地INSERT,UPDATE，以及一些 DELETE操作時(shí)，如何觀察是否有麻煩出現(xiàn)，那時(shí)候你就會(huì)不得不手忙腳亂地去閱讀Oracle的文獻(xiàn)。 不過(guò)我有一個(gè)解決辦法，該方法只需要檢查你的T-SQL代碼，很少的調(diào)整和系統(tǒng)測(cè)試。用該方法教你進(jìn)行適當(dāng)?shù)南到y(tǒng)測(cè)試過(guò)程。
鎖爭(zhēng)用的解決方法
如果你在今年6月－8月之間訪問(wèn)Streamload.com，你可能會(huì)看到諸如“遇到死鎖”，“鎖超時(shí)”， “需要對(duì)象”等錯(cuò)誤。這些錯(cuò)誤都是由于鎖爭(zhēng)用引起的。在查閱大量文檔和討論后，我了解了這方面的知識(shí)，也就是上面所論述的內(nèi)容，我再次敘述如下：
SQL Server開始是用行級(jí)鎖的，但是經(jīng)常會(huì)擴(kuò)大為頁(yè)面鎖和表鎖，最終造成死鎖。
即使用戶沒(méi)有修改數(shù)據(jù)，SQL Server在SELECT的時(shí)候也會(huì)遇到鎖。幸運(yùn)的是，我們可以通過(guò)SQL Server 的兩個(gè)關(guān)鍵字來(lái)手工處理：NOLOCK和ROWLOCK。
它們的使用方法如下：
SELECT COUNT(UserID)
FROM Users WITH (NOLOCK)
WHERE Username LIKE 'foobar'
和
UPDATE Users WITH (ROWLOCK)
SET Username = 'fred' WHERE Username = 'foobar'
NOLOCK的使用
NOLOCK可以忽略鎖，直接從數(shù)據(jù)庫(kù)讀取數(shù)據(jù)。這意味著可以避開鎖，從而提高性能和擴(kuò)展性。但同時(shí)也意味著代碼出錯(cuò)的可能性存在。你可能會(huì)讀取到運(yùn)行事務(wù)正在處理的無(wú)須驗(yàn)證的未遞交數(shù)據(jù)。 這種風(fēng)險(xiǎn)可以量化。
如果是金融方面的代碼或者一些非常規(guī)的總計(jì)(你想絕對(duì)保證安全性)，你應(yīng)該小心行事并且不使用這種技術(shù)。 但是我認(rèn)為使用該技術(shù)會(huì)比你90%應(yīng)用系統(tǒng)性能要好，當(dāng)用戶(或者是交互代碼)發(fā)現(xiàn)一個(gè)未遞交的修改時(shí)，使用技術(shù)會(huì)保證不會(huì)像未使用該技術(shù)那樣引起大麻煩。實(shí)際上，你可能發(fā)現(xiàn)你的大多數(shù)數(shù)據(jù)很少或者甚至不進(jìn)行 修改的，這樣我們就不會(huì)因?yàn)檫@些數(shù)據(jù)被鎖住而浪費(fèi)大量的時(shí)間。
例如，如果你想統(tǒng)計(jì)在2000年6月份到8月份之間加入Streamload.com的所有用戶，就沒(méi)有理由去鎖住任何記錄： 2000年9月1號(hào)一到來(lái)，這個(gè)用戶數(shù)就是確定的。又例如要列舉在Streamload.com的文件列表：這種結(jié)果即使 不是100%的正確，也不是大問(wèn)題。因?yàn)槟阋床粨碛性撐募?dāng)然也無(wú)所謂你是否能找到它，或者你確實(shí)擁有該文件，這種情況下你當(dāng)然知道你是否修改了該文件，以及該文件是否已經(jīng)上傳完畢了。
但是，如果這些數(shù)據(jù)的修改，對(duì)數(shù)據(jù)庫(kù)來(lái)說(shuō)是基礎(chǔ)性的修改，或者這些數(shù)據(jù)對(duì)于用戶來(lái)說(shuō)，必須是百分之百保證 是修改正確的(例如帳單或者余額數(shù)據(jù))，那么你不要使用該技術(shù)。
ROWLOCK的使用
ROWLOCK告訴SQL Server只使用行級(jí)鎖。ROWLOCK語(yǔ)法可以使用在SELECT,UPDATE和DELETE語(yǔ)句中，不過(guò) 我習(xí)慣僅僅在UPDATE和DELETE語(yǔ)句中使用。如果在UPDATE語(yǔ)句中有指定的主鍵，那么就總是會(huì)引發(fā)行級(jí)鎖的。但是當(dāng)SQL Server對(duì)幾個(gè)這種UPDATE進(jìn)行批處理時(shí)，某些數(shù)據(jù)正好在同一個(gè)頁(yè)面(page)，這種情況在當(dāng)前情況下 是很有可能發(fā)生的，這就象在一個(gè)目錄中，創(chuàng)建文件需要較長(zhǎng)的時(shí)間，而同時(shí)你又在更新這些文件。當(dāng)頁(yè)面鎖引發(fā)后，事情就開始變得糟糕了。而如果在UPDATE或者DELETE時(shí)，沒(méi)有指定主鍵，數(shù)據(jù)庫(kù)當(dāng)然認(rèn)為很多數(shù)據(jù)會(huì)收到影響，那樣 就會(huì)直接引發(fā)頁(yè)面鎖，事情同樣變得糟糕。
通過(guò)指定使用行級(jí)鎖，這種情況可以得到避免。但是需要小心的是，如果你錯(cuò)誤地使用在過(guò)多行上，數(shù)據(jù)庫(kù)并不會(huì)聰明到自動(dòng)將行級(jí)鎖升級(jí)到頁(yè)面鎖，服務(wù)器也會(huì)因?yàn)樾屑?jí)鎖的開銷而消耗大量的內(nèi)存和CPU，直至無(wú)法響應(yīng)。尤其主要留意的是 企業(yè)管理器中"管理/當(dāng)前活動(dòng)"(Management/Current Activity)這一項(xiàng)。該項(xiàng)會(huì)花較長(zhǎng)的時(shí)間來(lái)載入鎖的信息。這些信息 時(shí)十分有用的，當(dāng)你使用行級(jí)鎖后，你如果在"鎖/處理"(Locks/Processes)下看到幾百個(gè)鎖，一點(diǎn)都不奇怪，而恰恰應(yīng)該慶幸鎖超時(shí)和死鎖的問(wèn)題減少了。
注意事項(xiàng)
我認(rèn)為SQL Server傾向于使用NOLOCK關(guān)鍵字，而ROWLOCK關(guān)鍵字由用戶根據(jù)情況自行決定。你可以僅僅在 SELECT語(yǔ)句中使用NOLOCK，這些SELECT語(yǔ)句場(chǎng)合包括INNER查詢，以及在INSERT語(yǔ)句中的SELECT使用，在連接查詢下也可以使用，例如：
SELECT COUNT(Users.UserID)
FROM Users WITH (NOLOCK)
JOIN UsersInUserGroups WITH (NOLOCK) ON
Users.UserID = UsersInUserGroups.UserID
NOLOCK 和 ROWLOCK的使用效果
很難去量化在使用NOLOCK和ROWLOCK后，Streamload.com或者你的網(wǎng)站性能到底改善了多少。 不過(guò)在使用NOLOCK和ROWLOCK前，Streamload.com的速度很慢，而且經(jīng)常無(wú)法使用，以及很不穩(wěn)定。使用后，就變得快速、容易訪問(wèn)以及穩(wěn)定了。兩者簡(jiǎn)直就是天壤之別。這些改變當(dāng)然無(wú)法在 關(guān)于鎖的文檔中很難找到。那些文檔會(huì)建議你重寫你的應(yīng)用，當(dāng)表數(shù)據(jù)被使用，鎖產(chǎn)生了(沒(méi)錯(cuò)，就是這樣)，然后你應(yīng)該使用小事務(wù)并且以批處理的形式執(zhí)行(不錯(cuò)，實(shí)際經(jīng)驗(yàn)就是如此)，使用低級(jí)別的隔離措施 (也沒(méi)錯(cuò)，NOLOCK就是一個(gè)極端的例子)，還建議你有限的連接，從而讓處理器進(jìn)行合作(好復(fù)雜的描述，而且總覺(jué)得怪怪的不像個(gè)好點(diǎn)子)。我不知道是否用數(shù)據(jù)庫(kù)咨詢師會(huì)提到本文中的技術(shù)(或類似的技術(shù))， 但是我只想說(shuō)的是，Streamload.com的運(yùn)行狀況的確因?yàn)樵摷夹g(shù)得到了改善。如果你遇到了鎖爭(zhēng)用的問(wèn)題，也可以試試NOLOCK和ROWLOCK。
申明
是否使用NOLOCK和ROWLOCK，需要自行判斷，并謹(jǐn)慎運(yùn)用。我用該技術(shù)的方法是通過(guò)查看我的存儲(chǔ)過(guò)程和即時(shí)查詢語(yǔ)句，在我自己的理解上來(lái)覺(jué)得哪里用和如何用。我需要判斷如果用NOLOCK 而引起一些返回的不準(zhǔn)確，或者ROWLOCK是否會(huì)造成太多的鎖，這些情況出現(xiàn)時(shí)，對(duì)于訪問(wèn)者或者使用者來(lái)說(shuō)，是否是可以接受的。在大多數(shù)情況下，我認(rèn)為是沒(méi)有問(wèn)題的，但是也許你的代碼不適用， 你需要小心對(duì)待。你需要?jiǎng)?chuàng)建一些獨(dú)立的過(guò)程，是否加鎖，如何加鎖，以作為對(duì)比。當(dāng)UPDATE或者 DELETE查詢影響到很多數(shù)據(jù)行時(shí)，你在使用PAGELOCK,TABLOCK時(shí)也會(huì)遇到別的問(wèn)題。