導(dǎo)讀
全局鎖
- 全局鎖簡單的說就是鎖住整個(gè)數(shù)據(jù)庫實(shí)例，命令是
Flush tables with read lock。當(dāng)你需要為整個(gè)數(shù)據(jù)庫處于只讀的狀態(tài)的時(shí)候，可以使用這個(gè)命令。
- 一旦使用全局鎖，之后其他線程的以下語句會(huì)被阻塞：數(shù)據(jù)更新語句（數(shù)據(jù)的增刪改）、數(shù)據(jù)定義語句（包括建表、修改表結(jié)構(gòu)等）和更新類事務(wù)的提交語句。
- 全局鎖的使用場(chǎng)景大部分都是用來數(shù)據(jù)庫備份。
為什么備份要加全局鎖？
- 用戶買東西，首先會(huì)從余額里扣除金額，然后在訂單里添加商品。如果備份數(shù)據(jù)庫，不加鎖，并且備份順序?yàn)橄葌浞萦糜囝~，再備份訂單商品，有可能備份了用戶余額后，用戶下訂單買東西提交事務(wù)，然后再備份訂單商品表， 此時(shí)訂單商品已存在。最后備份出來的數(shù)據(jù)為。最后用戶余額為買東西前的余額，沒有減少，但是訂單商品卻多了。演示如下圖：
- 這種情況可能用戶會(huì)覺得賺了，但是如果備份順序反過來，先備份商品表再備份余額表，用戶就會(huì)發(fā)現(xiàn)我付了錢，但是商品沒有加，這中結(jié)果就會(huì)更加的嚴(yán)重。
- 因此保證備份數(shù)據(jù)的一致性很重要，必要的手段就是加鎖。
全局鎖有什么壞處？
- 全局鎖是個(gè)啥？介紹完了讀者心里已經(jīng)有數(shù)了，讓這個(gè)庫只讀？這是多么可怕的操作，簡單列舉幾個(gè)危險(xiǎn)之處：
- 如果在主庫備份，備份期間不能執(zhí)行任何更新操作，會(huì)導(dǎo)致整個(gè)業(yè)務(wù)停擺，高并發(fā)情況下更甚。
- 如果你在從庫上備份，那么備份期間從庫不能執(zhí)行主庫同步過來的binlog，會(huì)導(dǎo)致主從延遲。
全局備份比較好的解決方案
- 全局鎖遠(yuǎn)瞅不錯(cuò)，近瞅嚇一跳，陳某在此不推薦使用。
- 其實(shí) 官方自帶的邏輯備份工具是mysqldump。當(dāng)mysqldump使用參數(shù)**–single-transaction**的時(shí)候，導(dǎo)數(shù)據(jù)之前就會(huì)啟動(dòng)一個(gè)事務(wù)，來確保拿到一致性視圖。而由于MVCC的支持，這個(gè)過程中數(shù)據(jù)是可以正常更新的。
- 一致性備份是好，但前提是存儲(chǔ)引擎支持事務(wù)，這也是MyISAM被InnoDB取代的原因之一。
表級(jí)鎖
- MySQL里面表級(jí)別的鎖有兩種：一種是表鎖，一種是元數(shù)據(jù)鎖（meta data lock，MDL)。
- 表鎖一般是在數(shù)據(jù)庫引擎不支持行鎖的時(shí)候才會(huì)被用到的 。
- MDL會(huì)直到事務(wù)提交才釋放，在做表結(jié)構(gòu)變更的時(shí)候，你一定要小心不要導(dǎo)致鎖住線上查詢和更新 。
如何加表鎖
lock tables tb_name read/write;
unlock tables;
- 需要注意，lock tables語法除了會(huì)限制別的線程的讀寫外，也限定了本線程接下來的操作對(duì)象。
- 舉個(gè)例子, 如果在某個(gè)線程A中執(zhí)行lock tables t1 read, t2 write; 這個(gè)語句，則其他線程寫t1、讀寫t2的語句都會(huì)被阻塞。同時(shí)，線程A在執(zhí)行unlock tables之前，也只能執(zhí)行讀t1、讀寫t2的操作。連寫t1都不允許，自然也不能訪問其他表。
MDL
- MDL不需要顯式使用，在訪問一個(gè)表的時(shí)候會(huì)被自動(dòng)加上。
- 當(dāng)對(duì)一個(gè)表做增刪改查操作的時(shí)候，加MDL讀鎖；當(dāng)要對(duì)表做結(jié)構(gòu)變更操作的時(shí)候，加MDL寫鎖。
- 讀鎖之間不互斥，因此你可以有多個(gè)線程同時(shí)對(duì)一張表增刪改查。
- 讀寫鎖之間、寫鎖之間是互斥的，用來保證變更表結(jié)構(gòu)操作的安全性。因此，如果有兩個(gè)線程要同時(shí)給一個(gè)表加字段，其中一個(gè)要等另一個(gè)執(zhí)行完才能開始執(zhí)行。
查詢表級(jí)鎖爭用
- 查詢表級(jí)鎖的爭用可以通過以下參數(shù)分析獲得：
Table_locks_immediate：能夠立即獲得表級(jí)鎖的次數(shù)Table_locks_waited： 不能立即獲取表級(jí)鎖而需要等待的次數(shù)
- 查詢語句如下：
show status like 'table_locks_waited'
- 如果
Table_locks_waited的值比較大，則說明存在著較嚴(yán)重的表級(jí)鎖爭用情況。
行級(jí)鎖
- MySQL的行鎖是在引擎層由各個(gè)引擎自己實(shí)現(xiàn)的。但并不是所有的引擎都支持行鎖，比如MyISAM引擎就不支持行鎖。不支持行鎖意味著并發(fā)控制只能使用表鎖，對(duì)于這種引擎的表，同一張表上任何時(shí)刻只能有一個(gè)更新在執(zhí)行，這就會(huì)影響到業(yè)務(wù)并發(fā)度。InnoDB是支持行鎖的，這也是MyISAM被InnoDB替代的重要原因之一。
- InnoDB的行鎖是針對(duì)索引加的鎖，不是針對(duì)記錄加的鎖。并且該索引不能失效，否則都會(huì)從行鎖升級(jí)為表鎖。
- 在InnoDB事務(wù)中，行鎖是在需要的時(shí)候才加上的，但并不是不需要了就立刻釋放，而是要等到事務(wù)結(jié)束時(shí)才釋放。
- 行級(jí)鎖分為排它鎖（寫鎖）、共享鎖（讀鎖）、間隙鎖。
排他鎖
- 排他鎖，也稱寫鎖，獨(dú)占鎖，當(dāng)前寫操作沒有完成前，它會(huì)阻斷其他寫鎖和讀鎖。
- Mysql中的更新語句(update/delete/insert)會(huì)自動(dòng)加上排它鎖。
- 如上圖，事務(wù)B中的update語句被阻塞了，直到事務(wù)A提交才能執(zhí)行更新操作。
- 排他鎖也可以手動(dòng)添加，如下：
select * from user where id=1 for update;
- 注意以下兩點(diǎn)：
- 行鎖是針對(duì)索引加鎖的，上述例子中id是主鍵索引。
- 加了排他鎖并不是其他的事務(wù)不能讀取這行的數(shù)據(jù)，而是不能再在這行上面加鎖了。
間隙鎖
- 當(dāng)我們用范圍條件檢索數(shù)據(jù)，并請(qǐng)求共享或排他鎖時(shí)，InnoDB會(huì)給符合條件的已有數(shù)據(jù)記錄的索引項(xiàng)加鎖；對(duì)于鍵值在條件范圍內(nèi)但并不存在的記錄，叫做"間隙(GAP)"。InnoDB也會(huì)對(duì)這個(gè)"間隙"加鎖，這種鎖機(jī)制就是所謂的間隙鎖(Next-Key鎖)。
- 如上圖，給id>5中并不存在的數(shù)據(jù)加上了間隙鎖，當(dāng)插入id=6的數(shù)據(jù)時(shí)被阻塞了。
- 這是一個(gè)坑：若執(zhí)行的條件是范圍過大，則InnoDB會(huì)將整個(gè)范圍內(nèi)所有的索引鍵值全部鎖定，很容易對(duì)性能造成影響
共享鎖
- 共享鎖，也稱讀鎖，多用于判斷數(shù)據(jù)是否存在，多個(gè)讀操作可以同時(shí)進(jìn)行而不會(huì)互相影響。當(dāng)如果事務(wù)對(duì)讀鎖進(jìn)行修改操作，很可能會(huì)造成死鎖。如下圖所示。
分析行鎖定
- 通過檢查InnoDB_row_lock 狀態(tài)變量分析系統(tǒng)上的行鎖的爭奪情況 。
show status like 'innodb_row_lock%'
- innodb_row_lock_current_waits: 當(dāng)前正在等待鎖定的數(shù)量。
- innodb_row_lock_time: 從系統(tǒng)啟動(dòng)到現(xiàn)在鎖定總時(shí)間長度；非常重要的參數(shù)
- innodb_row_lock_time_avg: 每次等待所花平均時(shí)間；非常重要的參數(shù)。
- innodb_row_lock_time_max: 從系統(tǒng)啟動(dòng)到現(xiàn)在等待最常的一次所花的時(shí)間；
- innodb_row_lock_waits: 系統(tǒng)啟動(dòng)后到現(xiàn)在總共等待的次數(shù)；非常重要的參數(shù)。直接決定優(yōu)化的方向和策略。
死鎖解決方案
1、直接進(jìn)入等待，直到超時(shí)。這個(gè)超時(shí)時(shí)間可以通過參數(shù)innodb_lock_wait_timeout來設(shè)置，默認(rèn)50秒。注意超時(shí)時(shí)間不能設(shè)置太短，如果僅僅是短暫的等待，一旦設(shè)置時(shí)間很短，很快便解鎖了，會(huì)出現(xiàn)誤傷。
2、發(fā)起死鎖檢測(cè)，發(fā)現(xiàn)死鎖后，主動(dòng)回滾死鎖鏈條中的某一個(gè)事務(wù)，讓其他事務(wù)得以繼續(xù)執(zhí)行。將參數(shù)innodb_deadlock_detect設(shè)置為on，表示開啟這個(gè)邏輯，默認(rèn)開啟。 主動(dòng)死鎖檢測(cè)在發(fā)生死鎖的時(shí)候，是能夠快速發(fā)現(xiàn)并進(jìn)行處理的，但是它也是有額外負(fù)擔(dān)的。 當(dāng)并發(fā)很高的時(shí)候，檢測(cè)死鎖將會(huì)消耗大量的資源，因此控制并發(fā)也是很重要的一種策略。
|
