日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
MySQL死鎖問題實例分析及解決方法

MySQL死鎖問題的相關(guān)知識是本文我們主要要介紹的內(nèi)容，接下來我們就來一一介紹這部分內(nèi)容，希望能夠?qū)δ兴鶐椭?/p>

創(chuàng)新互聯(lián)建站是專業(yè)的大興網(wǎng)站建設(shè)公司，大興接單;提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進行大興網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

1、MySQL常用存儲引擎的鎖機制

MyISAM和MEMORY采用表級鎖(table-level locking)

BDB采用頁面鎖(page-level locking)或表級鎖，默認為頁面鎖

InnoDB支持行級鎖(row-level locking)和表級鎖,默認為行級鎖

2、各種鎖特點

表級鎖：開銷小,加鎖快;不會出現(xiàn)死鎖;鎖定粒度大,發(fā)生鎖沖突的概率***,并發(fā)度***

行級鎖：開銷大,加鎖慢;會出現(xiàn)死鎖;鎖定粒度最小,發(fā)生鎖沖突的概率***,并發(fā)度也***

頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間;會出現(xiàn)死鎖;鎖定粒度界于表鎖和行鎖之間,并發(fā)度一般

3、各種鎖的適用場景

表級鎖更適合于以查詢?yōu)橹?只有少量按索引條件更新數(shù)據(jù)的應用,如Web應用

行級鎖則更適合于有大量按索引條件并發(fā)更新數(shù)據(jù),同時又有并發(fā)查詢的應用,如一些在線事務(wù)處理系統(tǒng)

4、死鎖

是指兩個或兩個以上的進程在執(zhí)行過程中,因爭奪資源而造成的一種互相等待的現(xiàn)象,若無外力作用,它們都將無法推進下去。

表級鎖不會產(chǎn)生死鎖.所以解決死鎖主要還是針對于最常用的InnoDB.

5、死鎖舉例分析

在MySQL中，行級鎖并不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條sql語句操作了主鍵索引，MySQL就會鎖定這條主鍵索引；如果一條語句操作了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關(guān)的主鍵索引。

在UPDATE、DELETE操作時，MySQL不僅鎖定WHERE條件掃描過的所有索引記錄，而且會鎖定相鄰的鍵值，即所謂的next-key locking。

例如，一個表db.tab_test，結(jié)構(gòu)如下：

id：主鍵；

state：狀態(tài)；

time：時間；

索引：idx_1 (state, time)

出現(xiàn)死鎖日志如下：

 
 
 
    
  
  
  
  1. ***(1) TRANSACTION:  
    2.   
  
  
  2. TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starting index read  
    3.   
  
  
  3. mysql tables in use 1, locked 1  
    4.   
  
  
  4. LOCK WAIT 3 lock struct(s), heap size 320  
    5.   
  
  
  5. MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update  
    6.   
  
  
  6. update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute) （任務(wù)1的sql語句）  
    7.   
  
  
  7. ***(1) WAITING FOR THIS LOCK TO BE GRANTED: （任務(wù)1等待的索引記錄）  
    8.   
  
  
  8. RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting  
    9.   
  
  
  9. Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0  
    10.   
  
  
  10. 0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 75706c6f6164666972652e636f6d2f6 8616e642e706870; asc xxx.com/;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;  
    11.   
  
  
  11. *** (2) TRANSACTION:  
    12.   
  
  
  12. TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499  
    13.   
  
  
  13. mysql tables in use 1, locked 1  
    14.   
  
  
  14. 3 lock struct(s), heap size 320, undo log entries 1  
    15.   
  
  
  15. MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) （任務(wù)2的sql語句）  
    16.   
  
  
  16. *** (2) HOLDS THE LOCK(S): （任務(wù)2已獲得的鎖）  
    17.   
  
  
  17. RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap  
    18.   
  
  
  18. Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0  
    19.   
  
  
  19. 0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 75706c6f6164666972652e636f6d2f6 8616e642e706870; asc uploadfire.com/hand.php;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;  
    20.   
  
  
  20. *** (2) WAITING FOR THIS LOCK TO BE GRANTED: （任務(wù)2等待的鎖）  
    21.   
  
  
  21. RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting   
    22.   
  
  
  22. Record lock, heap no 395 PHYSICAL RECORD: n_fields 3; compact format; info bits 0  
    23.   
  
  
  23. 0: len 8; hex 8000000000000425; asc %;; 1: len 8; hex 800012412c66d29c; asc A,f ;; 2: len 8; hex 800000000097629c; asc b ;;  
    24.   
  
  
  24. *** WE ROLL BACK TRANSACTION (1)  
    25.   
  
  
  25. （回滾了任務(wù)1，以解除死鎖） 
    26.

原因分析：

當“update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute)”執(zhí)行時，MySQL會使用idx_1索引，因此首先鎖定相關(guān)的索引記錄，因為idx_1是非主鍵索引，為執(zhí)行該語句，MySQL還會鎖定主鍵索引。

假設(shè)“update tab_test set state=1067,time=now () where id in (9921180)”幾乎同時執(zhí)行時，本語句首先鎖定主鍵索引，由于需要更新state的值，所以還需要鎖定idx_1的某些索引記錄。

這樣***條語句鎖定了idx_1的記錄，等待主鍵索引，而第二條語句則鎖定了主鍵索引記錄，而等待idx_1的記錄，這樣死鎖就產(chǎn)生了。

6、解決辦法

拆分***條sql，先查出符合條件的主鍵值，再按照主鍵更新記錄：

 
 
 
    
  
  
  
  1. select id from tab_test where state=1061 and time < date_sub(now(), INTERVAL 30 minute);  
    2.   
  
  
  2. update tab_test state=1064,time=now() where id in(......); 
    3.

關(guān)于MySQL死鎖問題的實例分析及解決方法就介紹到這里了，希望本次的介紹能夠?qū)δ兴斋@！


當前標題：MySQL死鎖問題實例分析及解決方法
分享路徑：http://www.5511xx.com/article/dpdhihp.html