[TOC] ## mysql的鎖了解么，如何分類？ 可以從四個維度給鎖分類，分別如下：  ## 樂觀鎖和悲觀鎖是什么，如何實現？ 1、樂觀鎖：先修改，保存時判斷是夠被更新過，應用級別，說白了就是自己寫代碼實現，是一種思想，可以基于版本號、更新時間戳可以實現， 2、悲觀鎖：先獲取鎖，再操作修改，數據庫級別，比如sql后綴寫 for update，是基于MySQL自帶的功能。 ## 鎖的粒度有哪幾種？ 表級鎖：開銷小，加鎖快，粒度大，鎖沖突概率大，并發度低，適用于讀多寫少的情況。 頁級鎖：BDB存儲引擎 行級鎖：Innodb存儲引擎，默認選項 注意，innoDB中行級鎖是加在索引上的，因此只有命中索引的情況才會是行級鎖，不然是表級鎖， ## 鎖的兼容性對比 * S鎖：也叫做讀鎖、共享鎖，對應于`select * from users where id =1 lock in share mode` * X鎖：也叫做寫鎖、排它鎖、獨占鎖、互斥鎖，對應于`select * from users where id =1 for update` ## 什么是mysql的鎖機制 數據庫為了保證數據的一致性而設計的面對并發場景的一種規則。最顯著的特點是不同的存儲引擎支持不同的鎖機制，InnoDB支持行鎖和表鎖，MyISAM支持表鎖。 1. 表鎖就是把整張表鎖起來，特點是加鎖快，開銷小，不會出現死鎖，鎖粒度大，發生鎖沖突的概率高，并發相對較低。 2. 行鎖就是以行為單位把數據鎖起來，特點是加鎖慢，開銷大，會出現死鎖，鎖粒度小，發生鎖沖突的概率低，并發度也相對表鎖較高。 ## 什么是死鎖 死鎖是指兩個或多個事務在同一資源上相互占用，并請求鎖定對方的資源，從而導致惡性循環的現象。 ## 死鎖產生的原因 * 死鎖是指兩個或多個事務在同一資源上相互占用，并請求鎖定對方占用的資源，從而導致惡性循環 * 當事務試圖以不同的順序鎖定資源時，就可能產生死鎖。多個事務同時鎖定同一個資源時也可能會產生死鎖 * 鎖的行為和順序和存儲引擎相關。以同樣的順序執行語句，有些存儲引擎會產生死鎖有些不會——死鎖有雙重原因：真正的數據沖突；存儲引擎的實現方式。 ## 怎么解決死鎖 * 1、如果不同程序會并發存取多個表，盡量約定以相同的順序訪問表，可以大大降低死鎖機會。 * 2、在同一個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖產生概率； * 3、對于非常容易產生死鎖的業務部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產生的概率； * 4、 盡量按照索引去查數據，范圍查找增加了鎖沖突的可能性。 ## InnoDB InnoDB 實現了以下兩種類型的行鎖： * 共享鎖（S）：允許一個事務去讀一行，阻止其他事務獲得相同數據集的排他鎖。select?...?lock?in?share?mode; * 排他鎖（X）：允許獲得排他鎖的事務更新數據，阻止其他事務取得相同數據集的共享讀鎖和排他寫鎖。select?...?for?update； 為了允許行鎖和表鎖共存，實現多粒度鎖機制，InnoDB 還有兩種內部使用的意向鎖（Intention Locks），這兩種意向鎖都是**表鎖**： * 意向共享鎖（IS）：事務打算給數據行加行共享鎖，事務在給一個數據行加共享鎖前必須先取得該表的 IS 鎖。 * 意向排他鎖（IX）：事務打算給數據行加行排他鎖，事務在給一個數據行加排他鎖前必須先取得該表的 IX 鎖。 **索引失效會導致行鎖變表鎖** ### InnoDB存儲引擎的鎖的算法有三種 * Record lock：單個行記錄上的鎖 * Gap lock：間隙鎖，鎖定一個范圍，不包括記錄本身 * Next-key lock：record+gap 鎖定一個范圍，包含記錄本身 #### 相關知識點： * innodb對于行的查詢使用next-key lock * Next-locking keying為了解決Phantom Problem幻讀問題 * 當查詢的索引含有唯一屬性時，將next-key lock降級為record key * Gap鎖設計的目的是為了阻止多個事務將記錄插入到同一范圍內，而這會導致幻讀問題的產生 * 有兩種方式顯式關閉gap鎖：（除了外鍵約束和唯一性檢查外，其余情況僅使用record lock） A. 將事務隔離級別設置為RC B. 將參數innodb_locks_unsafe_for_binlog設置為1 ### 檢測死鎖 數據庫系統實現了各種死鎖檢測和死鎖超時的機制。InnoDB存儲引擎能檢測到死鎖的循環依賴并立即返回一個錯誤。innodb_deadlock_detect 配置 ### 死鎖恢復 死鎖發生以后，只有部分或完全回滾其中一個事務，才能打破死鎖，InnoDB目前處理死鎖的方法是，將持有最少行級排他鎖的事務進行回滾。所以事務型應用程序在設計時必須考慮如何處理死鎖，多數情況下只需要重新執行因死鎖回滾的事務即可。 ### 外部鎖的死鎖檢測 發生死鎖后，InnoDB 一般都能自動檢測到，并使一個事務釋放鎖并回退，另一個事務獲得鎖，繼續完成事務。但在涉及外部鎖，或涉及表鎖的情況下，InnoDB 并不能完全自動檢測到死鎖， 這需要通過設置鎖等待超時參數 innodb_lock_wait_timeout 來解決 ### 死鎖影響性能： 死鎖會影響性能而不是會產生嚴重錯誤，因為InnoDB會自動檢測死鎖狀況并回滾其中一個受影響的事務。在高并發系統上，當許多線程等待同一個鎖時，死鎖檢測可能導致速度變慢。有時當發生死鎖時，禁用死鎖檢測（使用`innodb_deadlock_detect`配置選項）可能會更有效，這時可以依賴`innodb_lock_wait_timeout`設置進行事務回滾。 ### 死鎖以及事務回滾的MYSQL的配置我們是怎么做的 1、innodb_deadlock_detect = off 2、innodb_lock_wait_timeout = 1 3、innodb_rollback_on_timeout = on 這樣配置的MYSQL 后, 1 在高并發的時候, innodb_deadlock_detect 影響性能的隱患解除了 2 我們可以根據系統的特性來設置 innodb_lock_wait_timeout 來針對不同的需求 3 設置innodb_rollback_on_timeout 設置后,整體的事務的原子性得到了保證. ### InnoDB避免死鎖： * 為了在單個InnoDB表上執行多個并發寫入操作時避免死鎖，可以在事務開始時通過為預期要修改的每個元祖（行）使用`SELECT ... FOR UPDATE`語句來獲取必要的鎖，即使這些行的更改語句是在之后才執行的。 * 在事務中，如果要更新記錄，應該直接申請足夠級別的鎖，即排他鎖，而不應先申請共享鎖、更新時再申請排他鎖，因為這時候當用戶再申請排他鎖時，其他事務可能又已經獲得了相同記錄的共享鎖，從而造成鎖沖突，甚至死鎖 * 如果事務需要修改或鎖定多個表，則應在每個事務中以相同的順序使用加鎖語句。在應用中，如果不同的程序會并發存取多個表，應盡量約定以相同的順序來訪問表，這樣可以大大降低產生死鎖的機會 * 通過SELECT ... LOCK IN SHARE MODE獲取行的讀鎖后，如果當前事務再需要對該記錄進行更新操作，則很有可能造成死鎖。 * 改變事務隔離級別 如果出現死鎖，可以用`show engine innodb status;`命令來確定最后一個死鎖產生的原因。返回結果中包括死鎖相關事務的詳細信息，如引發死鎖的 SQL 語句，事務已經獲得的鎖，正在等待什么鎖，以及被回滾的事務等。據此可以分析死鎖產生的原因和改進措施。 ## MyISAM MyISAM 的表鎖有兩種模式： * 表共享讀鎖 （Table Read Lock）：不會阻塞其他用戶對同一表的讀請求，但會阻塞對同一表的寫請求； * 表獨占寫鎖 （Table Write Lock）：會阻塞其他用戶對同一表的讀和寫操作； MyISAM 表的讀操作與寫操作之間，以及寫操作之間是串行的。當一個線程獲得對一個表的寫鎖后， 只有持有鎖的線程可以對表進行更新操作。其他線程的讀、 寫操作都會等待，直到鎖被釋放為止。 默認情況下，寫鎖比讀鎖具有更高的優先級：當一個鎖釋放時，這個鎖會優先給寫鎖隊列中等候的獲取鎖請求，然后再給讀鎖隊列中等候的獲取鎖請求。 //?顯式的添加表級讀鎖 LOCK?TABLE?表名?READ //?顯示的添加表級寫鎖 LOCK?TABLE?表名?WRITE //?顯式的解鎖（當一個事務commit的時候也會自動解鎖） unlock?tables; ### MyISAM避免死鎖(不會出現死鎖)： * 在自動加鎖的情況下，MyISAM 總是一次獲得 SQL 語句所需要的全部鎖，所以 MyISAM 表不會出現死鎖。 ## 間隙鎖 https://www.jianshu.com/p/32904ee07e56 https://zhuanlan.zhihu.com/p/48269420 ## mysql 是怎么加鎖的 https://mp.weixin.qq.com/s/8G-4V9-CC_lUblpvbo5Lkw ##### 其他 https://zhuanlan.zhihu.com/p/31875702 https://blog.csdn.net/qq\_38238296/article/details/88362999