mysql死結——mysql之四

來源:互聯網
上載者:User

標籤:

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

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

  BDB採用頁面鎖(page-level locking)或表級鎖,預設為頁面鎖

  InnoDB支援行級鎖(row-level locking)和表級鎖,預設為行級鎖

  2、各種鎖特點

  表級鎖:開銷小,加鎖快;不會出現死結;鎖定粒度大,發生鎖衝突的機率最高,並發度最低

  行級鎖:開銷大,加鎖慢;會出現死結;鎖定粒度最小,發生鎖衝突的機率最低,並發度也最高

  頁面鎖:開銷和加鎖時間界於表鎖和行鎖之間;會出現死結;鎖定粒度界於表鎖和行鎖之間,並發度一般

  3、各種鎖的適用情境

  表級鎖更適合於以查詢為主,只有少量按索引條件更新資料的應用,如Web應用

  行級鎖則更適合於有大量按索引條件並發更新資料,同時又有並發查詢的應用,如一些線上交易處理系統

  4、死結

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

  表級鎖不會產生死結。所以解決死結主要還是針對於最常用的InnoDB。

  5、死結舉例分析

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

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

  例如,一個表db。tab_test,結構如下:

  id:主鍵;

  state:狀態;

  time:時間;

  索引:idx_1(state,time)

  出現死結日誌如下:

 

  • ***(1) TRANSACTION:  
  • TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starting index read  
  • mysql tables in use 1, locked 1  
  • LOCK WAIT 3 lock struct(s), heap size 320  
  • MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update  
  • update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute) (任務1的sql語句)  
  • ***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任務1等待的索引記錄)  
  • 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  
  • Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0  
  • 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$;;  
  • *** (2) TRANSACTION:  
  • TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499  
  • mysql tables in use 1, locked 1  
  • 3 lock struct(s), heap size 320, undo log entries 1  
  • MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) (任務2的sql語句)  
  • *** (2) HOLDS THE LOCK(S): (任務2已獲得的鎖)  
  • 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  
  • Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0  
  • 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$;;  
  • *** (2) WAITING FOR THIS LOCK TO BE GRANTED: (任務2等待的鎖)  
  • 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   
  • Record lock, heap no 395 PHYSICAL RECORD: n_fields 3; compact format; info bits 0  
  • 0: len 8; hex 8000000000000425; asc %;; 1: len 8; hex 800012412c66d29c; asc A,f ;; 2: len 8; hex 800000000097629c; asc b ;;  
  • *** WE ROLL BACK TRANSACTION (1)  
  • (復原了任務1,以解除死結)

 

  原因分析:

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

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

  這樣第一條語句鎖定了idx_1的記錄,等待主鍵索引,而第二條語句則鎖定了主鍵索引記錄,而等待idx_1的記錄,這樣死結就產生了。

  6、解決辦法

  拆分第一條sql,先查出合格主索引值,再按照主鍵更新記錄: 

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

  7、解決辦法

  show engine innodb status \G;

mysql死結——mysql之四

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.