mysql 裡面的鎖大致可以分成全域性鎖、表級鎖和行鎖三類
全域性鎖mysql 提供了乙個加全域性讀鎖的方法，命令是 flush tables with read lock (ftwrl)。
當你需要讓整個庫處於唯讀狀態的時候，可以使用這個命令，之後其他執行緒的以下語句會被阻塞：資料更新語句（資料的增刪改）、資料定義語句（包括建表、修改表結構等）和更新類事務的提交語句。
風險:1.如果在主庫備份，在備份期間不能更新，業務停擺
2.如果在從庫備份，備份期間不能執行主庫同步的binlog，導致主從延遲
可重複讀的隔離級別，可以讓同乙個事務拿到一致性檢視，這個過程由mvcc支援 ，(myisam 不支援此事務所以需要ftwrl
表級鎖表鎖：lock tables … read/write
元資料鎖(mdl meta date lock): mdl 不需要顯式使用，在訪問乙個表的時候會被自動加上
mdl 鎖是系統缺省會加的,給乙個表加字段，或者修改字段，或者加索引，需要掃瞄全表的資料。而且事務中的 mdl 鎖，在語句執行開始時申請，但是語句結束後並不會馬上釋放，而會等到整個事務提交後再釋放
mdl 保證讀寫的正確性
當對乙個表做增刪改查操作的時候，加 mdl 讀鎖；當要對錶做結構變更操作的時候，加 mdl 寫鎖。
行級鎖兩階段協議:
在 innodb 事務中，行鎖是在需要的時候才加上的，但並不是不需要了就立刻釋放，而是要等到事務結束時才釋放。這個就是兩階段鎖協議。
針對兩階段協議做的優化
顧客在電影院買票的大概流程:
1、顧客賬戶餘額中扣除票錢
2、給影院增加賬戶餘額
3、記錄一條交易日誌
可見，多名客戶購買，需要修改的都會集中在步驟2，所以調整順序 3、1、2，最大程度減少事務中停留的時間
死鎖、死鎖檢查
誘因：不同執行緒迴圈資源依賴
事務 a 在等待事務 b 釋放 id=2 的行鎖，而事務 b 在等待事務 a 釋放 id=1 的行鎖。 事務 a 和事務 b 在互相等待對方的資源釋放，就是進入了死鎖狀態。當出現死鎖以後，有兩種策略：
1、一種策略是，直接進入等待，直到超時。這個超時時間可以通過引數 innodb_lock_wait_timeout 來設定。innodb預設50s
2、另一種策略是，發起死鎖檢測，發現死鎖後，主動回滾死鎖鏈條中的某乙個事務，讓其他事務得以繼續執行。將引數 innodb_deadlock_detect 設定為 on，表示開啟這個邏輯。
注: 死鎖檢查耗費大量的cpu資源。
死鎖檢查:
每當乙個事務被鎖的時候，就要看看它所依賴的執行緒有沒有被別人鎖住，如此迴圈，最後判斷是否出現了迴圈等待，也就是死鎖。
總結mysql的行鎖觸發的死鎖與死鎖檢測
死鎖策略:1、設定超時時間，預設50s 2、死鎖檢查(高併發cpu大量消耗)
熱點行更新效能問題:
1、臨時關閉死鎖檢查
2、應用層阻塞佇列、資料庫層阻塞佇列
3、邏輯上多行減少鎖衝突(業務複雜解決鎖衝突)
4、調整事務中邏輯順序
MySQL系列之鎖
分布式鎖 疑問？什麼是共享鎖？共享鎖 共享讀鎖，排他鎖 獨佔寫鎖 鎖機制與innodb鎖演算法 在關係型資料庫中，可以按照鎖的粒度把資料庫鎖分為行級鎖 innodb引擎 表級鎖 myisam引擎 和頁級鎖 bdb引擎 myisam採用表級鎖 table level locking innodb支援行...
mysql行鎖 死鎖 mysql行鎖和死鎖檢測
行鎖顧名思義，就是針對單行資料加鎖，在mysql中，鎖的實現是由引擎層實現的,myisam引擎就不支援行鎖 不支援行鎖就意味著併發控制只能使用表鎖，也就是說同一時間，在這個表上只能有乙個更新在執行，這就會 影響到業務的併發度。innodb是支援行鎖的，這也是myisam被innodb替代的重要原因之...
Mysql系列之鎖機制
一般乙個程式滿，從消耗的角度，乙個是cpu，乙個是io，但有的時候mysql慢，是因為某條sql不小心把整個表給鎖了。鎖是計算機協調多個程序或執行緒併發訪問某一資源的機制。在資料庫中，除了傳統的計算機資源 如cpu，ram，i o 的爭用外，資料也是供很多使用者共享的資源。如何保證資料併發訪問的一致...