JZOJ6915【2020.12.02提高組模擬】顯示器(display)
轉自:https://blog.csdn.net/qq_35246620/article/details/69943011
在電腦科學中,鎖是在執行多執行緒時用於強行限制資源訪問的同步機制,即用於在併發控制中保證對互斥要求的滿足。
在資料庫的鎖機制中,咱們介紹過在 DBMS 中,可以按照鎖的粒度把資料庫鎖分為行級鎖(InnoDB 引擎)、表級鎖(MyISAM 引擎)和頁級鎖(BDB 引擎)。
行級鎖
行級鎖是 MySQL 中鎖定粒度最細的一種鎖,表示只針對當前操作的行進行加鎖。行級鎖能大大減少資料庫操作的衝突,其加鎖粒度最小,但加鎖的開銷也最大。行級鎖分為共享鎖和排他鎖。
特點
開銷大,加鎖慢;會出現死鎖;鎖定粒度最小,發生鎖衝突的概率最低,併發度也最高。
表級鎖
表級鎖是 MySQL 中鎖定粒度最大的一種鎖,表示對當前操作的整張表加鎖,它實現簡單,資源消耗較少,被大部分 MySQL 引擎支援。最常使用的 MyISAM 與 InnoDB 都支援表級鎖定。表級鎖定分為表共享讀鎖(共享鎖)與表獨佔寫鎖(排他鎖)。
特點
開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發出鎖衝突的概率最高,併發度最低。
頁級鎖
頁級鎖是 MySQL 中鎖定粒度介於行級鎖和表級鎖中間的一種鎖。表級鎖速度快,但衝突多,行級衝突少,但速度慢。因此,採取了折衷的頁級鎖,一次鎖定相鄰的一組記錄。BDB 支援頁級鎖。
特點
開銷和加鎖時間界於表鎖和行鎖之間;會出現死鎖;鎖定粒度界於表鎖和行鎖之間,併發度一般。
MySQL 常用儲存引擎的鎖機制
- MyISAM 和 Memory 採用表級鎖(table-level locking)
- BDB 採用頁級鎖(page-level locking)或表級鎖,預設為頁級鎖;
- InnoDB 支援行級鎖(row-level locking)和表級鎖,預設為行級鎖。
InnoDB 中的行鎖與表鎖
前面提到過,在 InnoDB 引擎中既支援行鎖也支援表鎖,那麼什麼時候會鎖住整張表?什麼時候只鎖住一行呢?
InnoDB 行鎖是通過給索引上的索引項加鎖來實現的,這一點 MySQL 與 Oracle 不同,後者是通過在資料塊中對相應資料行加鎖來實現的。InnoDB 這種行鎖實現的特點意味著:只有通過索引條件檢索資料,InnoDB 才使用行級鎖,否則,InnoDB 將使用表鎖。
在實際應用中,要特別注意 InnoDB 行鎖的這一特性,不然的話,可能導致大量的鎖衝突,從而影響併發效能。
- 在不通過索引條件查詢的時候,InnoDB 確實使用的是表鎖,而不是行鎖。
- 由於 MySQL 的行鎖是針對索引加的鎖,不是針對記錄加的鎖,因此雖然是訪問不同行的記錄,但是如果是使用相同的索引鍵,是會出現鎖衝突的。應用設計的時候要注意這一點。
- 當表有多個索引的時候,不同的事務可以使用不同的索引鎖定不同的行,另外,不論是使用主鍵索引、唯一索引還是普通索引,InnoDB 都會使用行鎖來對資料加鎖。
- 即便在條件中使用了索引欄位,但是否使用索引來檢索資料是由 MySQL 通過判斷不同的執行計劃的代價來決定的。如果 MySQL 認為全表掃描效率更高,比如對一些很小的表,它就不會使用索引,這種情況下 InnoDB 將使用表鎖,而不是行鎖。因此,在分析鎖衝突時,別忘了檢查 SQL 的執行計劃,以確認是否真正使用了索引。
行級鎖與死鎖
MyISAM 中是不會產生死鎖的,因為 MyISAM 總是一次性獲得所需的全部鎖,要麼全部滿足,要麼全部等待。而在 InnoDB 中,鎖是逐步獲得的,就造成了死鎖的可能。
在 MySQL 中,行級鎖並不是直接鎖記錄,而是鎖索引。索引分為主鍵索引和非主鍵索引兩種,如果一條 SQL 語句操作了主鍵索引,MySQL 就會鎖定這條主鍵索引;如果一條 SQL 語句操作了非主鍵索引,MySQL 就會先鎖定該非主鍵索引,再鎖定相關的主鍵索引。 在進行UPDATE
、DELETE
操作時,MySQL 不僅鎖定WHERE
條件掃描過的所有索引記錄,而且會鎖定相鄰的鍵值,即所謂的next-key locking
.
當兩個事務同時執行,一個鎖住了主鍵索引,在等待其他相關索引;另一個鎖定了非主鍵索引,在等待主鍵索引。這樣就會發生死鎖。
發生死鎖後,InnoDB 一般都可以檢測到,並使一個事務釋放鎖回退,另一個獲取鎖完成事務。
避免死鎖的方法
有多種方法可以避免死鎖,這裡只介紹常見的三種:
- 如果不同程式會併發存取多個表,儘量約定以相同的順序訪問表,可以大大降低發生死鎖的可能性;
- 在同一個事務中,儘可能做到一次鎖定所需要的所有資源,減少死鎖產生概率;
- 對於非常容易產生死鎖的業務部分,可以嘗試使用升級鎖定顆粒度,通過表級鎖定來減少死鎖產生的概率。