高效能mysql之鎖詳解
阿新 • • 發佈：2019-02-16
是一個範圍條件的檢索，InnoDB不僅會對符合條件的empid值為101的記錄加鎖，也會對empid大於101（這些記錄並不存在）的“間隙”加鎖。
InnoDB使用間隙鎖的目的：
（1）防止幻讀，以滿足相關隔離級別的要求。對於上面的例子，要是不使用間隙鎖，如果其他事務插入了empid大於100的任何記錄，那麼本事務如果再次執行上述語句，就會發生幻讀；
（2）為了滿足其恢復和複製的需要。
很顯然，在使用範圍條件檢索並鎖定記錄時，即使某些不存在的鍵值也會被無辜的鎖定，而造成在鎖定的時候無法插入鎖定鍵值範圍內的任何資料。在某些場景下這可能會對效能造成很大的危害。
除了間隙鎖給InnoDB帶來效能的負面影響之外，通過索引實現鎖定的方式還存在其他幾個較大的效能隱患：
（1）當Query無法利用索引的時候，InnoDB會放棄使用行級別鎖定而改用表級別的鎖定，造成併發效能的降低；
（2）當Query使用的索引並不包含所有過濾條件的時候，資料檢索使用到的索引鍵所只想的資料可能有部分並不屬於該Query的結果集的行列，但是也會被鎖定，因為間隙鎖鎖定的是一個範圍，而不是具體的索引鍵；
（3）當Query在使用索引定位資料的時候，如果使用的索引鍵一樣但訪問的資料行不同的時候（索引只是過濾條件的一部分），一樣會被鎖定。
因此，在實際應用開發中，尤其是併發插入比較多的應用，我們要儘量優化業務邏輯，儘量使用相等條件來訪問更新資料，避免使用範圍條件。
還要特別說明的是，InnoDB除了通過範圍條件加鎖時使用間隙鎖外，如果使用相等條件請求給一個不存在的記錄加鎖，InnoDB也會使用間隙鎖。
4.死鎖
上文講過，MyISAM表鎖是deadlock free的，這是因為MyISAM總是一次獲得所需的全部鎖，要麼全部滿足，要麼等待，因此不會出現死鎖。但在InnoDB中，除單個SQL組成的事務外，鎖是逐步獲得的，當兩個事務都需要獲得對方持有的排他鎖才能繼續完成事務，這種迴圈鎖等待就是典型的死鎖。
在InnoDB的事務管理和鎖定機制中，有專門檢測死鎖的機制，會在系統中產生死鎖之後的很短時間內就檢測到該死鎖的存在。當InnoDB檢測到系統中產生了死鎖之後，InnoDB會通過相應的判斷來選這產生死鎖的兩個事務中較小的事務來回滾，而讓另外一個較大的事務成功完成。
那InnoDB是以什麼來為標準判定事務的大小的呢？MySQL官方手冊中也提到了這個問題，實際上在InnoDB發現死鎖之後，會計算出兩個事務各自插入、更新或者刪除的資料量來判定兩個事務的大小。也就是說哪個事務所改變的記錄條數越多，在死鎖中就越不會被回滾掉。
但是有一點需要注意的就是，當產生死鎖的場景中涉及到不止InnoDB儲存引擎的時候，InnoDB是沒辦法檢測到該死鎖的，這時候就只能通過鎖定超時限制引數InnoDB_lock_wait_timeout來解決。
需要說明的是，這個引數並不是只用來解決死鎖問題，在併發訪問比較高的情況下，如果大量事務因無法立即獲得所需的鎖而掛起，會佔用大量計算機資源，造成嚴重效能問題，甚至拖跨資料庫。我們通過設定合適的鎖等待超時閾值，可以避免這種情況發生。
通常來說，死鎖都是應用設計的問題，通過調整業務流程、資料庫物件設計、事務大小，以及訪問資料庫的SQL語句，絕大部分死鎖都可以避免。下面就通過例項來介紹幾種避免死鎖的常用方法：
（1）在應用中，如果不同的程式會併發存取多個表，應儘量約定以相同的順序來訪問表，這樣可以大大降低產生死鎖的機會。
（2）在程式以批量方式處理資料的時候，如果事先對資料排序，保證每個執行緒按固定的順序來處理記錄，也可以大大降低出現死鎖的可能。
（3）在事務中，如果要更新記錄，應該直接申請足夠級別的鎖，即排他鎖，而不應先申請共享鎖，更新時再申請排他鎖，因為當用戶申請排他鎖時，其他事務可能又已經獲得了相同記錄的共享鎖，從而造成鎖衝突，甚至死鎖。
（4）在REPEATABLE-READ隔離級別下，如果兩個執行緒同時對相同條件記錄用SELECT...FOR UPDATE加排他鎖，在沒有符合該條件記錄情況下，兩個執行緒都會加鎖成功。程式發現記錄尚不存在，就試圖插入一條新記錄，如果兩個執行緒都這麼做，就會出現死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可避免問題。
（5）當隔離級別為READ COMMITTED時，如果兩個執行緒都先執行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個執行緒能插入成功，另一個執行緒會出現鎖等待，當第1個執行緒提交後，第2個執行緒會因主鍵重出錯，但雖然這個執行緒出錯了，卻會獲得一個排他鎖。這時如果有第3個執行緒又來申請排他鎖，也會出現死鎖。對於這種情況，可以直接做插入操作，然後再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執行ROLLBACK釋放獲得的排他鎖。
5.什麼時候使用表鎖
對於InnoDB表，在絕大部分情況下都應該使用行級鎖，因為事務和行鎖往往是我們之所以選擇InnoDB表的理由。但在個別特殊事務中，也可以考慮使用表級鎖：
（1）事務需要更新大部分或全部資料，表又比較大，如果使用預設的行鎖，不僅這個事務執行效率低，而且可能造成其他事務長時間鎖等待和鎖衝突，這種情況下可以考慮使用表鎖來提高該事務的執行速度。
（2）事務涉及多個表，比較複雜，很可能引起死鎖，造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表，從而避免死鎖、減少資料庫因事務回滾帶來的開銷。
當然，應用中這兩種事務不能太多，否則，就應該考慮使用MyISAM表了。
在InnoDB下，使用表鎖要注意以下兩點。
（1）使用LOCK TABLES雖然可以給InnoDB加表級鎖，但必須說明的是，表鎖不是由InnoDB儲存引擎層管理的，而是由其上一層──MySQL Server負責的，僅當autocommit=0、InnoDB_table_locks=1（預設設定）時，InnoDB層才能知道MySQL加的表鎖，MySQL Server也才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動識別涉及表級鎖的死鎖，否則，InnoDB將無法自動檢測並處理這種死鎖。
（2）在用 LOCK TABLES對InnoDB表加鎖時要注意，要將AUTOCOMMIT設為0，否則MySQL不會給表加鎖；事務結束前，不要用UNLOCK TABLES釋放表鎖，因為UNLOCK TABLES會隱含地提交事務；COMMIT或ROLLBACK並不能釋放用LOCK TABLES加的表級鎖，必須用UNLOCK TABLES釋放表鎖。正確的方式見如下語句：
例如，如果需要寫表t1並從表t讀，可以按如下做：
InnoDB使用間隙鎖的目的：
（1）防止幻讀，以滿足相關隔離級別的要求。對於上面的例子，要是不使用間隙鎖，如果其他事務插入了empid大於100的任何記錄，那麼本事務如果再次執行上述語句，就會發生幻讀；
（2）為了滿足其恢復和複製的需要。
很顯然，在使用範圍條件檢索並鎖定記錄時，即使某些不存在的鍵值也會被無辜的鎖定，而造成在鎖定的時候無法插入鎖定鍵值範圍內的任何資料。在某些場景下這可能會對效能造成很大的危害。
除了間隙鎖給InnoDB帶來效能的負面影響之外，通過索引實現鎖定的方式還存在其他幾個較大的效能隱患：
（1）當Query無法利用索引的時候，InnoDB會放棄使用行級別鎖定而改用表級別的鎖定，造成併發效能的降低；
（2）當Query使用的索引並不包含所有過濾條件的時候，資料檢索使用到的索引鍵所只想的資料可能有部分並不屬於該Query的結果集的行列，但是也會被鎖定，因為間隙鎖鎖定的是一個範圍，而不是具體的索引鍵；
（3）當Query在使用索引定位資料的時候，如果使用的索引鍵一樣但訪問的資料行不同的時候（索引只是過濾條件的一部分），一樣會被鎖定。
因此，在實際應用開發中，尤其是併發插入比較多的應用，我們要儘量優化業務邏輯，儘量使用相等條件來訪問更新資料，避免使用範圍條件。
還要特別說明的是，InnoDB除了通過範圍條件加鎖時使用間隙鎖外，如果使用相等條件請求給一個不存在的記錄加鎖，InnoDB也會使用間隙鎖。
4.死鎖
上文講過，MyISAM表鎖是deadlock free的，這是因為MyISAM總是一次獲得所需的全部鎖，要麼全部滿足，要麼等待，因此不會出現死鎖。但在InnoDB中，除單個SQL組成的事務外，鎖是逐步獲得的，當兩個事務都需要獲得對方持有的排他鎖才能繼續完成事務，這種迴圈鎖等待就是典型的死鎖。
在InnoDB的事務管理和鎖定機制中，有專門檢測死鎖的機制，會在系統中產生死鎖之後的很短時間內就檢測到該死鎖的存在。當InnoDB檢測到系統中產生了死鎖之後，InnoDB會通過相應的判斷來選這產生死鎖的兩個事務中較小的事務來回滾，而讓另外一個較大的事務成功完成。
那InnoDB是以什麼來為標準判定事務的大小的呢？MySQL官方手冊中也提到了這個問題，實際上在InnoDB發現死鎖之後，會計算出兩個事務各自插入、更新或者刪除的資料量來判定兩個事務的大小。也就是說哪個事務所改變的記錄條數越多，在死鎖中就越不會被回滾掉。
但是有一點需要注意的就是，當產生死鎖的場景中涉及到不止InnoDB儲存引擎的時候，InnoDB是沒辦法檢測到該死鎖的，這時候就只能通過鎖定超時限制引數InnoDB_lock_wait_timeout來解決。
需要說明的是，這個引數並不是只用來解決死鎖問題，在併發訪問比較高的情況下，如果大量事務因無法立即獲得所需的鎖而掛起，會佔用大量計算機資源，造成嚴重效能問題，甚至拖跨資料庫。我們通過設定合適的鎖等待超時閾值，可以避免這種情況發生。
通常來說，死鎖都是應用設計的問題，通過調整業務流程、資料庫物件設計、事務大小，以及訪問資料庫的SQL語句，絕大部分死鎖都可以避免。下面就通過例項來介紹幾種避免死鎖的常用方法：
（1）在應用中，如果不同的程式會併發存取多個表，應儘量約定以相同的順序來訪問表，這樣可以大大降低產生死鎖的機會。
（2）在程式以批量方式處理資料的時候，如果事先對資料排序，保證每個執行緒按固定的順序來處理記錄，也可以大大降低出現死鎖的可能。
（3）在事務中，如果要更新記錄，應該直接申請足夠級別的鎖，即排他鎖，而不應先申請共享鎖，更新時再申請排他鎖，因為當用戶申請排他鎖時，其他事務可能又已經獲得了相同記錄的共享鎖，從而造成鎖衝突，甚至死鎖。
（4）在REPEATABLE-READ隔離級別下，如果兩個執行緒同時對相同條件記錄用SELECT...FOR UPDATE加排他鎖，在沒有符合該條件記錄情況下，兩個執行緒都會加鎖成功。程式發現記錄尚不存在，就試圖插入一條新記錄，如果兩個執行緒都這麼做，就會出現死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可避免問題。
（5）當隔離級別為READ COMMITTED時，如果兩個執行緒都先執行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個執行緒能插入成功，另一個執行緒會出現鎖等待，當第1個執行緒提交後，第2個執行緒會因主鍵重出錯，但雖然這個執行緒出錯了，卻會獲得一個排他鎖。這時如果有第3個執行緒又來申請排他鎖，也會出現死鎖。對於這種情況，可以直接做插入操作，然後再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執行ROLLBACK釋放獲得的排他鎖。
5.什麼時候使用表鎖
對於InnoDB表，在絕大部分情況下都應該使用行級鎖，因為事務和行鎖往往是我們之所以選擇InnoDB表的理由。但在個別特殊事務中，也可以考慮使用表級鎖：
（1）事務需要更新大部分或全部資料，表又比較大，如果使用預設的行鎖，不僅這個事務執行效率低，而且可能造成其他事務長時間鎖等待和鎖衝突，這種情況下可以考慮使用表鎖來提高該事務的執行速度。
（2）事務涉及多個表，比較複雜，很可能引起死鎖，造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表，從而避免死鎖、減少資料庫因事務回滾帶來的開銷。
當然，應用中這兩種事務不能太多，否則，就應該考慮使用MyISAM表了。
在InnoDB下，使用表鎖要注意以下兩點。
（1）使用LOCK TABLES雖然可以給InnoDB加表級鎖，但必須說明的是，表鎖不是由InnoDB儲存引擎層管理的，而是由其上一層──MySQL Server負責的，僅當autocommit=0、InnoDB_table_locks=1（預設設定）時，InnoDB層才能知道MySQL加的表鎖，MySQL Server也才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動識別涉及表級鎖的死鎖，否則，InnoDB將無法自動檢測並處理這種死鎖。
（2）在用 LOCK TABLES對InnoDB表加鎖時要注意，要將AUTOCOMMIT設為0，否則MySQL不會給表加鎖；事務結束前，不要用UNLOCK TABLES釋放表鎖，因為UNLOCK TABLES會隱含地提交事務；COMMIT或ROLLBACK並不能釋放用LOCK TABLES加的表級鎖，必須用UNLOCK TABLES釋放表鎖。正確的方式見如下語句：
例如，如果需要寫表t1並從表t讀，可以按如下做：