MySQL并發(fā)控制
并發(fā)即指在同一時刻，多個操作并行執(zhí)行。MySQL對并發(fā)的處理主要應(yīng)用了兩種機制——是“鎖”和“多版本控制”。
鎖
鎖分為讀鎖和寫鎖兩種，也稱作共享鎖和排他鎖。
因為多個讀操作同時進行是不會破壞數(shù)據(jù)的，所以讀鎖是共享的，多個讀操作可以同時進行，互不干擾。
為了防止多個寫操作共同執(zhí)行破壞數(shù)據(jù)，寫鎖是排他的，一個寫鎖會阻塞其它的寫鎖和讀鎖，進而保證同一資源在任何時刻只有一個寫操作在執(zhí)行，并防止其它用戶讀取正在寫入的該資源。
在鎖粒度方面，MySQL包括表鎖和行鎖兩種類型。鎖的粒度越小，越有利于對數(shù)據(jù)庫操作的并發(fā)執(zhí)行。但是管理鎖消耗的資源也會更多。如果系統(tǒng)花費大量的時間來管理鎖，而不是存儲數(shù)據(jù)，那么系統(tǒng)的性能也會受到影響。
表鎖會鎖定整張表，它是開銷最小的策略。諸如ALTER TABLE之類的語句會使用表鎖。
行鎖***程度的支持并發(fā)操作，同時也帶來了***的開銷。InnoDB實現(xiàn)了行鎖。
在MySql中并不只是用鎖來維護并發(fā)控制。
事務(wù)的隔離級別
事務(wù)的概念在此不多介紹。我覺得，也可以將事務(wù)看成是并發(fā)中的一部分——事務(wù)包含了一組操作，事務(wù)和事務(wù)之間可以并行執(zhí)行。事務(wù)和事務(wù)之間的并發(fā)也和普通的并發(fā)操作一樣會共享相同的資源，這樣并發(fā)執(zhí)行的事務(wù)之間就會相互影響。根據(jù)事務(wù)之間影響程度的不同，提出了事務(wù)的隔離級別這個概念，分別是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE。
READ UNCOMMITTED就是一個事務(wù)對共享數(shù)據(jù)的修改馬上就能夠被另一個事務(wù)感知到，其實也就是沒有對修改操作做任何特殊處理。
SERIALIZABLE是通過加鎖的方式強制事務(wù)串行執(zhí)行，這樣可以避免幻讀。但這種方式會帶來大量鎖爭用問題。
READ COMMITTED和REPEATABLE READ是基于MVCC的方式實現(xiàn)的。
MVCC多版本并發(fā)控制
MySql對于事務(wù)之間并發(fā)控制的實現(xiàn)并不是簡單的使用行級鎖。MySql在讀操作時并不加鎖，只有在寫操作時才會對修改的資源加鎖。
MVCC保存了數(shù)據(jù)資源在不同時間點上的多個快照。根據(jù)事務(wù)開始的時間不同，每個事務(wù)看到的數(shù)據(jù)快照版本是不一樣的。
InnoDB中的MVCC實現(xiàn)：存儲引擎全局維護了一個系統(tǒng)版本號，每開啟一個新的事務(wù)，這個系統(tǒng)版本號就會遞增。事務(wù)開始時刻的系統(tǒng)版本號，會作為這個事務(wù)本身的版本號。在每行記錄中，存儲引擎又在每行的后面保存兩個隱藏的列，分別保存這一行的開始版本號和過期版本號。在REPEATABLE READ隔離級別下，MVCC的具體操作如下：
- INSERT
存儲引擎為新插入的每一行保存當(dāng)前的系統(tǒng)版本號作為這一行的開始版本號。
- UPDATE
存儲引擎會新插入一行記錄，當(dāng)前的系統(tǒng)版本號就是新記錄行的開始版本號。同時會將原來行的過期版本號設(shè)為當(dāng)前的系統(tǒng)版本號。
- DELETE
存儲引擎將刪除的記錄行的過期版本號設(shè)置為當(dāng)前的系統(tǒng)版本號。
- SELECT
當(dāng)讀取記錄時，存儲引擎會選取滿足下面兩個條件的行作為讀取結(jié)果。
1. 讀取記錄行的開始版本號必須早于當(dāng)前事務(wù)的版本號。也就是說，在當(dāng)前事務(wù)開始之前，這條記錄已經(jīng)存在。在事務(wù)開始之后才插入的行，事務(wù)不會看到。
2. 讀取記錄行的過期版本號必須晚于當(dāng)前事務(wù)的版本號。也就是說，當(dāng)前事務(wù)開始的時候，這條記錄還沒有過期。在事務(wù)開始之前就已經(jīng)過期的數(shù)據(jù)行，該事務(wù)也不會看到。
通過上面的描述，可以看到在存儲引擎中，同一時刻存儲了一個數(shù)據(jù)行的多個版本。每個事務(wù)會根據(jù)自己的版本號和每個數(shù)據(jù)行的開始及過期版本號選擇讀取合適的數(shù)據(jù)行。
MVCC只在READ COMMITTED和REPEATABLE READ這兩個級別下工作。
