{eval=Array;=+count(Array);}
真相只有一個(gè)!你的設(shè)計(jì)太水了。。
我在有一個(gè)問題《數(shù)據(jù)庫(kù)什么時(shí)候會(huì)死鎖》的回答中提到了,數(shù)據(jù)庫(kù)為了保證數(shù)據(jù)的一致性,防止并發(fā)對(duì)數(shù)據(jù)正確性的影響,通常會(huì)使用加鎖的方式!
而一共有表級(jí)鎖,行級(jí)鎖和頁(yè)面鎖三種鎖粒度,鎖又有共享鎖(通常用于讀數(shù)據(jù))和獨(dú)占鎖(通常用于寫數(shù)據(jù))等的區(qū)分!
關(guān)于數(shù)據(jù)庫(kù)鎖機(jī)制發(fā)生死鎖的原因,請(qǐng)參考我的那篇回答,回到這個(gè)提問上來,為什么數(shù)據(jù)庫(kù)經(jīng)常鎖表?
鎖表的意思很明顯,就是表數(shù)據(jù)被鎖,導(dǎo)致其他事務(wù)訪問不到表中的數(shù)據(jù)!可能原因有哪些呢?
1,字段不加索引:在執(zhí)行事務(wù)的時(shí)候,如果表中沒有索引,會(huì)執(zhí)行全表掃描,如果這時(shí)候有其他的事務(wù)過來,就會(huì)發(fā)生鎖表!
2,事務(wù)處理時(shí)間長(zhǎng):事務(wù)處理時(shí)間較長(zhǎng),當(dāng)越來越多事務(wù)堆積的時(shí)候,會(huì)發(fā)生鎖表!
3,關(guān)聯(lián)操作太多:涉及到很多張表的修改等,在并發(fā)量大的時(shí)候,會(huì)造成大量表數(shù)據(jù)被鎖!
出現(xiàn)鎖表應(yīng)該怎么解決呢?
1,通過相關(guān)的sql語句可以查出是否被鎖定,和被鎖定的數(shù)據(jù)!
2,為加鎖進(jìn)行時(shí)間限定,防止無限死鎖!
3,加索引,避免全表掃描!
4,盡量順序操作數(shù)據(jù)!
5,根據(jù)引擎選擇合理的鎖粒度!
6,事務(wù)中的處理時(shí)間盡量短!
生產(chǎn)中出現(xiàn)死鎖等問題是比較嚴(yán)重的問題,因?yàn)橥ǔK梨i沒有明顯的錯(cuò)誤日志,只有在發(fā)現(xiàn)錯(cuò)誤的時(shí)候才能后知后覺的處理,所以,一定要盡力避免!
由于篇幅原因,就不再贅述,改天再寫下數(shù)據(jù)庫(kù)鎖的機(jī)制和死鎖原因和解決方案,敬請(qǐng)關(guān)注。。
對(duì)于開發(fā)運(yùn)維和DBA而言,數(shù)據(jù)庫(kù)鎖表現(xiàn)象并不陌生。當(dāng)遇到鎖表時(shí)并沒有什么好辦法,只能多做檢查,當(dāng)然了這種檢查也不是漫無目的的檢查。
我們知道,數(shù)據(jù)庫(kù)會(huì)涉及到多人讀取和寫入,數(shù)據(jù)庫(kù)為了保證ACID特性(原子性、一致性、隔離性、持久性)會(huì)對(duì)數(shù)據(jù)做相應(yīng)保護(hù)措施(鎖表)。通俗來說就是,為了防止在數(shù)據(jù)變更時(shí)別人也在同時(shí)變更,就需要把表先鎖住不讓別人修改,等數(shù)據(jù)修改完畢后再釋放鎖。
如果某個(gè)表長(zhǎng)時(shí)間處于鎖定狀態(tài),那可能是競(jìng)爭(zhēng)資源引起了進(jìn)程死鎖(即:多個(gè)進(jìn)程互相在等待對(duì)方釋放鎖)。導(dǎo)致數(shù)據(jù)庫(kù)長(zhǎng)時(shí)間鎖定/死鎖表的可能因素主要有:
1、事務(wù)處理時(shí)間較長(zhǎng),在并發(fā)較大情況下容易導(dǎo)致死鎖;
2、表未加索引導(dǎo)致全表掃描,耗時(shí)較久;
3、多個(gè)進(jìn)程間存在循環(huán)等待條件,每個(gè)都占用對(duì)方申請(qǐng)的下一個(gè)資源。
不同數(shù)據(jù)庫(kù)定位鎖表的方法不盡相同,此處以SQL Server為例看看如何定位被鎖的表。SQL Server可通過SQL Server Profiler檢測(cè)工具來查找,步聚如下:
以上就是我的觀點(diǎn),對(duì)于這個(gè)問題大家是怎么看待的呢?歡迎在下方評(píng)論區(qū)交流 ~ 我是科技領(lǐng)域創(chuàng)作者,十年互聯(lián)網(wǎng)從業(yè)經(jīng)驗(yàn),歡迎關(guān)注我了解更多科技知識(shí)!
0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答