MySQL學習之——鎖(行鎖、表鎖、頁鎖、樂觀鎖、悲觀鎖等)

原創 一位失去梦想变成咸鱼的乘客 2020-02-21 04:05

標籤：

鎖，在現實生活中是爲我們想要隱藏於外界所使用的一種工具。在計算機中，是協調多個進程或縣城併發訪問某一資源的一種機制。在數據庫當中，除了傳統的計算資源（CPU、RAM、I/O等等）的爭用之外，數據也是一種供許多用戶共享訪問的資源。如何保證數據併發訪問的一致性、有效性，是所有數據庫必須解決的一個問題，鎖的衝突也是影響數據庫併發訪問性能的一個重要因素。從這一角度來說，鎖對於數據庫而言就顯得尤爲重要。

 

MySQL鎖

相對於其他的數據庫而言，MySQL的鎖機制比較簡單，最顯著的特點就是不同的存儲引擎支持不同的鎖機制。根據不同的存儲引擎，MySQL中鎖的特性可以大致歸納如下：

 

  行鎖 表鎖 頁鎖
MyISAM   √  
BDB   √ √
InnoDB √ √  

 

 

開銷、加鎖速度、死鎖、粒度、併發性能

 

  • 表鎖：開銷小，加鎖快；不會出現死鎖；鎖定力度大，發生鎖衝突概率高，併發度最低
  • 行鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度小，發生鎖衝突的概率低，併發度高
  • 頁鎖：開銷和加鎖速度介於表鎖和行鎖之間；會出現死鎖；鎖定粒度介於表鎖和行鎖之間，併發度一般

 

從上述的特點課件，很難籠統的說哪種鎖最好，只能根據具體應用的特點來說哪種鎖更加合適。僅僅從鎖的角度來說的話：

表鎖更適用於以查詢爲主，只有少量按索引條件更新數據的應用；行鎖更適用於有大量按索引條件併發更新少量不同數據，同時又有併發查詢的應用。（PS：由於BDB已經被InnoDB所取代，我們只討論MyISAM表鎖和InnoDB行鎖的問題）

 

 

MyISAM表鎖
MyISAM存儲引擎只支持表鎖，這也是MySQL開始幾個版本中唯一支持的鎖類型。隨着應用對事務完整性和併發性要求的不斷提高，MySQL纔開始開發基於事務的存儲引擎，後來慢慢出現了支持頁鎖的BDB存儲引擎和支持行鎖的InnoDB存儲引擎（實際 InnoDB是單獨的一個公司，現在已經被Oracle公司收購）。但是MyISAM的表鎖依然是使用最爲廣泛的鎖類型。本節將詳細介紹MyISAM表鎖的使用。
查詢表級鎖爭用情況
可以通過檢查table_locks_waited和table_locks_immediate狀態變量來分析系統上的表鎖定爭奪：
mysql> show status like ‘table%‘;
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Table_locks_immediate | 2979  |
| Table_locks_waited    | 0     |
+-----------------------+-------+
2 rows in set (0.00 sec))
如果Table_locks_waited的值比較高，則說明存在着較嚴重的表級鎖爭用情況。

MySQL表級鎖的鎖模式

MySQL的表級鎖有兩種模式：表共享讀鎖（Table Read Lock）和表獨佔寫鎖（Table Write Lock）。鎖模式的兼容性如下表所示。
                                          MySQL中的表鎖兼容性                
請求鎖模式
         是否兼容
當前鎖模式
 None 讀鎖 寫鎖
讀鎖 是 是 否
寫鎖 是 否 否
可見，對MyISAM表的讀操作，不會阻塞其他用戶對同一表的讀請求，但會阻塞對同一表的寫請求；對 MyISAM表的寫操作，則會阻塞其他用戶對同一表的讀和寫操作；MyISAM表的讀操作與寫操作之間，以及寫操作之間是串行的！根據如下表所示的例子可以知道，當一個線程獲得對一個表的寫鎖後，只有持有鎖的線程可以對錶進行更新操作。其他線程的讀、寫操作都會等待，直到鎖被釋放爲止。
                        MyISAM存儲引擎的寫阻塞讀例子
session_1 session_2
獲得表film_text的WRITE鎖定
mysql> lock table film_text write;
Query OK, 0 rows affected (0.00 sec)
  
當前session對鎖定表的查詢、更新、插入操作都可以執行：
mysql> select film_id,title from film_text where film_id = 1001;
+---------+-------------+
| film_id | title       |
+---------+-------------+
| 1001    | Update Test |
+---------+-------------+
1 row in set (0.00 sec)
mysql> insert into film_text (film_id,title) values(1003,‘Test‘);
Query OK, 1 row affected (0.00 sec)
mysql> update film_text set title = ‘Test‘ where film_id = 1001;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
其他session對鎖定表的查詢被阻塞，需要等待鎖被釋放：
mysql> select film_id,title from film_text where film_id = 1001;
等待
釋放鎖：
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)
 等待
 
Session2獲得鎖，查詢返回：
mysql> select film_id,title from film_text where film_id = 1001;
+---------+-------+
| film_id | title |
+---------+-------+
| 1001    | Test  |
+---------+-------+
1 row in set (57.59 sec)
 

如何加表鎖

MyISAM在執行查詢語句（SELECT）前，會自動給涉及的所有表加讀鎖，在執行更新操作（UPDATE、DELETE、INSERT等）前，會自動給涉及的表加寫鎖，這個過程並不需要用戶干預，因此，用戶一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。在本書的示例中，顯式加鎖基本上都是爲了方便而已，並非必須如此。
給MyISAM表顯示加鎖，一般是爲了在一定程度模擬事務操作，實現對某一時間點多個表的一致性讀取。例如，有一個訂單表orders，其中記錄有各訂單的總金額total，同時還有一個訂單明細表order_detail，其中記錄有各訂單每一產品的金額小計 subtotal，假設我們需要檢查這兩個表的金額合計是否相符，可能就需要執行如下兩條SQL：
Select sum(total) from orders;
Select sum(subtotal) from order_detail;
這時，如果不先給兩個表加鎖，就可能產生錯誤的結果，因爲第一條語句執行過程中，order_detail表可能已經發生了改變。因此，正確的方法應該是：
Lock tables orders read local, order_detail read local;
Select sum(total) from orders;
Select sum(subtotal) from order_detail;
Unlock tables;
要特別說明以下兩點內容。
  • 上面的例子在LOCK TABLES時加了“local”選項，其作用就是在滿足MyISAM表併發插入條件的情況下，允許其他用戶在表尾併發插入記錄，有關MyISAM表的併發插入問題，在後面的章節中還會進一步介紹。
  • 在用LOCK TABLES給表顯式加表鎖時，必須同時取得所有涉及到表的鎖，並且MySQL不支持鎖升級。也就是說，在執行LOCK TABLES後，只能訪問顯式加鎖的這些表，不能訪問未加鎖的表；同時，如果加的是讀鎖，那麼只能執行查詢操作，而不能執行更新操作。其實，在自動加鎖的情況下也基本如此，MyISAM總是一次獲得SQL語句所需要的全部鎖。這也正是MyISAM表不會出現死鎖（Deadlock Free）的原因。
在如下表所示的例子中，一個session使用LOCK TABLE命令給表film_text加了讀鎖，這個session可以查詢鎖定表中的記錄，但更新或訪問其他表都會提示錯誤；同時，另外一個session可以查詢表中的記錄，但更新就會出現鎖等待。

 

 

MyISAM存儲引擎的讀阻塞寫例子
session_1 session_2
獲得表film_text的READ鎖定
mysql> lock table film_text read;
Query OK, 0 rows affected (0.00 sec)
  
當前session可以查詢該表記錄
mysql> select film_id,title from film_text where film_id = 1001;
+---------+------------------+
| film_id | title            |
+---------+------------------+
| 1001    | ACADEMY DINOSAUR |
+---------+------------------+
1 row in set (0.00 sec)
其他session也可以查詢該表的記錄
mysql> select film_id,title from film_text where film_id = 1001;
+---------+------------------+
| film_id | title            |
+---------+------------------+
| 1001    | ACADEMY DINOSAUR |
+---------+------------------+
1 row in set (0.00 sec)
當前session不能查詢沒有鎖定的表
mysql> select film_id,title from film where film_id = 1001;
ERROR 1100 (HY000): Table ‘film‘ was not locked with LOCK TABLES
其他session可以查詢或者更新未鎖定的表
mysql> select film_id,title from film where film_id = 1001;
+---------+---------------+
| film_id | title         |
+---------+---------------+
| 1001    | update record |
+---------+---------------+
1 row in set (0.00 sec)
mysql> update film set title = ‘Test‘ where film_id = 1001;
Query OK, 1 row affected (0.04 sec)
Rows matched: 1  Changed: 1  Warnings: 0
當前session中插入或者更新鎖定的表都會提示錯誤：
mysql> insert into film_text (film_id,title) values(1002,‘Test‘);
ERROR 1099 (HY000): Table ‘film_text‘ was locked with a READ lock and can‘t be updated
mysql> update film_text set title = ‘Test‘ where film_id = 1001;
ERROR 1099 (HY000): Table ‘film_text‘ was locked with a READ lock and can‘t be updated
其他session更新鎖定表會等待獲得鎖：
mysql> update film_text set title = ‘Test‘ where film_id = 1001;
等待
釋放鎖
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)
 等待
 
Session獲得鎖，更新操作完成：
mysql> update film_text set title = ‘Test‘ where film_id = 1001;
Query OK, 1 row affected (1 min 0.71 sec)
Rows matched: 1  Changed: 1  Warnings: 0

注意，當使用LOCK TABLES時，不僅需要一次鎖定用到的所有表，而且，同一個表在SQL語句中出現多少次，就要通過與SQL語句中相同的別名鎖定多少次，否則也會出錯！舉例說明如下。
（1）對actor表獲得讀鎖：
mysql> lock table actor read;
Query OK, 0 rows affected (0.00 sec)
（2）但是通過別名訪問會提示錯誤：
mysql> select a.first_name,a.last_name,b.first_name,b.last_name from actor a,actor b where a.first_name = b.first_name and a.first_name = ‘Lisa‘ and a.last_name = ‘Tom‘ and a.last_name <> b.last_name;
ERROR 1100 (HY000): Table ‘a‘ was not locked with LOCK TABLES
（3）需要對別名分別鎖定：
mysql> lock table actor as a read,actor as b read;
Query OK, 0 rows affected (0.00 sec)
（4）按照別名的查詢可以正確執行：
mysql> select a.first_name,a.last_name,b.first_name,b.last_name from actor a,actor b where a.first_name = b.first_name and a.first_name = ‘Lisa‘ and a.last_name = ‘Tom‘ and a.last_name <> b.last_name;
+------------+-----------+------------+-----------+
| first_name | last_name | first_name | last_name |
+------------+-----------+------------+-----------+
| Lisa       | Tom       | LISA       | MONROE    |
+------------+-----------+------------+-----------+
1 row in set (0.00 sec)

併發插入（Concurrent Inserts）

上文提到過MyISAM表的讀和寫是串行的，但這是就總體而言的。在一定條件下，MyISAM表也支持查詢和插入操作的併發進行。
MyISAM存儲引擎有一個系統變量concurrent_insert，專門用以控制其併發插入的行爲，其值分別可以爲0、1或2。
  • 當concurrent_insert設置爲0時，不允許併發插入。
  • 當concurrent_insert設置爲1時，如果MyISAM表中沒有空洞（即表的中間沒有被刪除的行），MyISAM允許在一個進程讀表的同時，另一個進程從表尾插入記錄。這也是MySQL的默認設置。
  • 當concurrent_insert設置爲2時，無論MyISAM表中有沒有空洞，都允許在表尾併發插入記錄。
在如下表所示的例子中，session_1獲得了一個表的READ LOCAL鎖，該線程可以對錶進行查詢操作，但不能對錶進行更新操作；其他的線程（session_2），雖然不能對錶進行刪除和更新操作，但卻可以對該表進行併發插入操作，這裏假設該表中間不存在空洞。
              MyISAM存儲引擎的讀寫（INSERT）併發例子
session_1 session_2
獲得表film_text的READ LOCAL鎖定
mysql> lock table film_text read local;
Query OK, 0 rows affected (0.00 sec)
  
當前session不能對鎖定表進行更新或者插入操作：
mysql> insert into film_text (film_id,title) values(1002,‘Test‘);
ERROR 1099 (HY000): Table ‘film_text‘ was locked with a READ lock and can‘t be updated
mysql> update film_text set title = ‘Test‘ where film_id = 1001;
ERROR 1099 (HY000): Table ‘film_text‘ was locked with a READ lock and can‘t be updated
其他session可以進行插入操作，但是更新會等待：
mysql> insert into film_text (film_id,title) values(1002,‘Test‘);
Query OK, 1 row affected (0.00 sec)
mysql> update film_text set title = ‘Update Test‘ where film_id = 1001;
等待
當前session不能訪問其他session插入的記錄：
mysql> select film_id,title from film_text where film_id = 1002;
Empty set (0.00 sec)
  
釋放鎖：
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)
 等待
當前session解鎖後可以獲得其他session插入的記錄：
mysql> select film_id,title from film_text where film_id = 1002;
+---------+-------+
| film_id | title |
+---------+-------+
| 1002    | Test  |
+---------+-------+
1 row in set (0.00 sec)
Session2獲得鎖，更新操作完成：
mysql> update film_text set title = ‘Update Test‘ where film_id = 1001;
Query OK, 1 row affected (1 min 17.75 sec)
Rows matched: 1  Changed: 1  Warnings: 0
可以利用MyISAM存儲引擎的併發插入特性，來解決應用中對同一表查詢和插入的鎖爭用。例如，將concurrent_insert系統變量設爲2，總是允許併發插入；同時，通過定期在系統空閒時段執行 OPTIMIZE TABLE語句來整理空間碎片，收回因刪除記錄而產生的中間空洞。有關OPTIMIZE TABLE語句的詳細介紹，可以參見第18章中“兩個簡單實用的優化方法”一節的內容。
 
MyISAM的鎖調度
前面講過，MyISAM存儲引擎的讀鎖和寫鎖是互斥的，讀寫操作是串行的。那麼，一個進程請求某個 MyISAM表的讀鎖，同時另一個進程也請求同一表的寫鎖，MySQL如何處理呢？答案是寫進程先獲得鎖。不僅如此，即使讀請求先到鎖等待隊列，寫請求後到，寫鎖也會插到讀鎖請求之前！這是因爲MySQL認爲寫請求一般比讀請求要重要。這也正是MyISAM表不太適合於有大量更新操作和查詢操作應用的原因，因爲，大量的更新操作會造成查詢操作很難獲得讀鎖，從而可能永遠阻塞。這種情況有時可能會變得非常糟糕！幸好我們可以通過一些設置來調節MyISAM 的調度行爲。
  • 通過指定啓動參數low-priority-updates，使MyISAM引擎默認給予讀請求以優先的權利。
  • 通過執行命令SET LOW_PRIORITY_UPDATES=1，使該連接發出的更新請求優先級降低。
  • 通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先級。
雖然上面3種方法都是要麼更新優先，要麼查詢優先的方法，但還是可以用其來解決查詢相對重要的應用（如用戶登錄系統）中，讀鎖等待嚴重的問題。
另外，MySQL也提供了一種折中的辦法來調節讀寫衝突，即給系統參數max_write_lock_count設置一個合適的值，當一個表的讀鎖達到這個值後，MySQL就暫時將寫請求的優先級降低，給讀進程一定獲得鎖的機會。
上面已經討論了寫優先調度機制帶來的問題和解決辦法。這裏還要強調一點：一些需要長時間運行的查詢操作，也會使寫進程“餓死”！因此，應用中應儘量避免出現長時間運行的查詢操作，不要總想用一條SELECT語句來解決問題，因爲這種看似巧妙的SQL語句，往往比較複雜，執行時間較長，在可能的情況下可以通過使用中間表等措施對SQL語句做一定的“分解”，使每一步查詢都能在較短時間完成，從而減少鎖衝突。如果複雜查詢不可避免，應儘量安排在數據庫空閒時段執行，比如一些定期統計可以安排在夜間執行。

 

 

 

InnoDB鎖問題
InnoDB與MyISAM的最大不同有兩點：一是支持事務（TRANSACTION）；二是採用了行級鎖。行級鎖與表級鎖本來就有許多不同之處，另外，事務的引入也帶來了一些新問題。下面我們先介紹一點背景知識，然後詳細討論InnoDB的鎖問題。
背景知識
1．事務（Transaction）及其ACID屬性
事務是由一組SQL語句組成的邏輯處理單元，事務具有以下4個屬性，通常簡稱爲事務的ACID屬性。
  • 原子性（Atomicity）：事務是一個原子操作單元，其對數據的修改，要麼全都執行，要麼全都不執行。
  • 一致性（Consistent）：在事務開始和完成時，數據都必須保持一致狀態。這意味着所有相關的數據規則都必須應用於事務的修改，以保持數據的完整性；事務結束時，所有的內部數據結構（如B樹索引或雙向鏈表）也都必須是正確的。
  • 隔離性（Isolation）：數據庫系統提供一定的隔離機制，保證事務在不受外部併發操作影響的“獨立”環境執行。這意味着事務處理過程中的中間狀態對外部是不可見的，反之亦然。
  • 持久性（Durable）：事務完成之後，它對於數據的修改是永久性的，即使出現系統故障也能夠保持。
銀行轉帳就是事務的一個典型例子。
2．併發事務處理帶來的問題
相對於串行處理來說，併發事務處理能大大增加數據庫資源的利用率，提高數據庫系統的事務吞吐量，從而可以支持更多的用戶。但併發事務處理也會帶來一些問題，主要包括以下幾種情況。
  • 更新丟失（Lost Update）：當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，由於每個事務都不知道其他事務的存在，就會發生丟失更新問題－－最後的更新覆蓋了由其他事務所做的更新。例如，兩個編輯人員製作了同一文檔的電子副本。每個編輯人員獨立地更改其副本，然後保存更改後的副本，這樣就覆蓋了原始文檔。最後保存其更改副本的編輯人員覆蓋另一個編輯人員所做的更改。如果在一個編輯人員完成並提交事務之前，另一個編輯人員不能訪問同一文件，則可避免此問題。
  • 髒讀（Dirty Reads）：一個事務正在對一條記錄做修改，在這個事務完成並提交前，這條記錄的數據就處於不一致狀態；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“髒”數據，並據此做進一步的處理，就會產生未提交的數據依賴關係。這種現象被形象地叫做"髒讀"。
  • 不可重複讀（Non-Repeatable Reads）：一個事務在讀取某些數據後的某個時間，再次讀取以前讀過的數據，卻發現其讀出的數據已經發生了改變、或某些記錄已經被刪除了！這種現象就叫做“不可重複讀”。
  • 幻讀（Phantom Reads）：一個事務按相同的查詢條件重新讀取以前檢索過的數據，卻發現其他事務插入了滿足其查詢條件的新數據，這種現象就稱爲“幻讀”。
3．事務隔離級別
在上面講到的併發事務處理帶來的問題中，“更新丟失”通常是應該完全避免的。但防止更新丟失，並不能單靠數據庫事務控制器來解決，需要應用程序對要更新的數據加必要的鎖來解決，因此，防止更新丟失應該是應用的責任。
“髒讀”、“不可重複讀”和“幻讀”，其實都是數據庫讀一致性問題，必須由數據庫提供一定的事務隔離機制來解決。數據庫實現事務隔離的方式，基本上可分爲以下兩種。
  • 一種是在讀取數據前，對其加鎖，阻止其他事務對數據進行修改。
  • 另一種是不用加任何鎖，通過一定機制生成一個數據請求時間點的一致性數據快照（Snapshot)，並用這個快照來提供一定級別（語句級或事務級）的一致性讀取。從用戶的角度來看，好像是數據庫可以提供同一數據的多個版本，因此，這種技術叫做數據多版本併發控制（MultiVersion Concurrency Control，簡稱MVCC或MCC），也經常稱爲多版本數據庫。
數據庫的事務隔離越嚴格，併發副作用越小，但付出的代價也就越大，因爲事務隔離實質上就是使事務在一定程度上 “串行化”進行，這顯然與“併發”是矛盾的。同時，不同的應用對讀一致性和事務隔離程度的要求也是不同的，比如許多應用對“不可重複讀”和“幻讀”並不敏感，可能更關心數據併發訪問的能力。
爲了解決“隔離”與“併發”的矛盾，ISO/ANSI SQL92定義了4個事務隔離級別，每個級別的隔離程度不同，允許出現的副作用也不同，應用可以根據自己的業務邏輯要求，通過選擇不同的隔離級別來平衡 “隔離”與“併發”的矛盾。下表很好地概括了這4個隔離級別的特性。
                                            4種隔離級別比較
讀數據一致性及允許的併發副作用
隔離級別
 讀數據一致性 髒讀 不可重複讀 幻讀
未提交讀（Read uncommitted）
 最低級別，只能保證不讀取物理上損壞的數據 是 是 是
已提交度（Read committed）
 語句級 否 是 是
可重複讀（Repeatable read）
 事務級 否 否 是
可序列化（Serializable）
 最高級別，事務級 否 否 否
最後要說明的是：各具體數據庫並不一定完全實現了上述4個隔離級別，例如，Oracle只提供Read committed和Serializable兩個標準隔離級別，另外還提供自己定義的Read only隔離級別；SQL Server除支持上述ISO/ANSI SQL92定義的4個隔離級別外，還支持一個叫做“快照”的隔離級別，但嚴格來說它是一個用MVCC實現的Serializable隔離級別。MySQL 支持全部4個隔離級別，但在具體實現時，有一些特點，比如在一些隔離級別下是採用MVCC一致性讀，但某些情況下又不是，這些內容在後面的章節中將會做進一步介紹。
 
獲取InnoDB行鎖爭用情況    
可以通過檢查InnoDB_row_lock狀態變量來分析系統上的行鎖的爭奪情況：
mysql> show status like ‘innodb_row_lock%‘;
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| InnoDB_row_lock_current_waits | 0     |
| InnoDB_row_lock_time          | 0     |
| InnoDB_row_lock_time_avg      | 0     |
| InnoDB_row_lock_time_max      | 0     |
| InnoDB_row_lock_waits         | 0     |
+-------------------------------+-------+
5 rows in set (0.01 sec)
如果發現鎖爭用比較嚴重，如InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比較高，還可以通過設置InnoDB Monitors來進一步觀察發生鎖衝突的表、數據行等，並分析鎖爭用的原因。
具體方法如下：
mysql> CREATE TABLE innodb_monitor(a INT) ENGINE=INNODB;
Query OK, 0 rows affected (0.14 sec)
然後就可以用下面的語句來進行查看：
mysql> Show innodb status\G;
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
…
…
------------
TRANSACTIONS
------------
Trx id counter 0 117472192
Purge done for trx‘s n:o < 0 117472190 undo n:o < 0 0
History list length 17
Total number of lock structs in row lock hash table 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 117472185, not started, process no 11052, OS thread id 1158191456
MySQL thread id 200610, query id 291197 localhost root
---TRANSACTION 0 117472183, not started, process no 11052, OS thread id 1158723936
MySQL thread id 199285, query id 291199 localhost root
Show innodb status
…
監視器可以通過發出下列語句來停止查看：
mysql> DROP TABLE innodb_monitor;
Query OK, 0 rows affected (0.05 sec)
設置監視器後，在SHOW INNODB STATUS的顯示內容中，會有詳細的當前鎖等待的信息，包括表名、鎖類型、鎖定記錄的情況等，便於進行進一步的分析和問題的確定。打開監視器以後，默認情況下每15秒會向日志中記錄監控的內容，如果長時間打開會導致.err文件變得非常的巨大，所以用戶在確認問題原因之後，要記得刪除監控表以關閉監視器，或者通過使用“--console”選項來啓動服務器以關閉寫日誌文件。
 
InnoDB的行鎖模式及加鎖方法
InnoDB實現了以下兩種類型的行鎖。
  • 共享鎖（S）：允許一個事務去讀一行，阻止其他事務獲得相同數據集的排他鎖。
  • 排他鎖（X)：允許獲得排他鎖的事務更新數據，阻止其他事務取得相同數據集的共享讀鎖和排他寫鎖。另外，爲了允許行鎖和表鎖共存，實現多粒度鎖機制，InnoDB還有兩種內部使用的意向鎖（Intention Locks），這兩種意向鎖都是表鎖。
  • 意向共享鎖（IS）：事務打算給數據行加行共享鎖，事務在給一個數據行加共享鎖前必須先取得該表的IS鎖。
  • 意向排他鎖（IX）：事務打算給數據行加行排他鎖，事務在給一個數據行加排他鎖前必須先取得該表的IX鎖。
上述鎖模式的兼容情況具體如下表所示。
                                         InnoDB行鎖模式兼容性列表
請求鎖模式
   是否兼容
當前鎖模式
 X IX S IS
X 衝突 衝突 衝突 衝突
IX 衝突 兼容 衝突 兼容
S 衝突 衝突 兼容 兼容
IS 衝突 兼容 兼容 兼容
如果一個事務請求的鎖模式與當前的鎖兼容，InnoDB就將請求的鎖授予該事務；反之，如果兩者不兼容，該事務就要等待鎖釋放。
意向鎖是InnoDB自動加的，不需用戶干預。對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數據集加排他鎖（X)；對於普通SELECT語句，InnoDB不會加任何鎖；事務可以通過以下語句顯示給記錄集加共享鎖或排他鎖。
  • 共享鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
  • 排他鎖（X)：SELECT * FROM table_name WHERE ... FOR UPDATE。
用SELECT ... IN SHARE MODE獲得共享鎖，主要用在需要數據依存關係時來確認某行記錄是否存在，並確保沒有人對這個記錄進行UPDATE或者DELETE操作。但是如果當前事務也需要對該記錄進行更新操作，則很有可能造成死鎖，對於鎖定行記錄後需要進行更新操作的應用，應該使用SELECT... FOR UPDATE方式獲得排他鎖。
在如下表所示的例子中，使用了SELECT ... IN SHARE MODE加鎖後再更新記錄，看看會出現什麼情況，其中actor表的actor_id字段爲主鍵。
  InnoDB存儲引擎的共享鎖例子
session_1 session_2
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> select actor_id,first_name,last_name from actor where actor_id = 178;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 178      | LISA       | MONROE    |
+----------+------------+-----------+
1 row in set (0.00 sec)
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> select actor_id,first_name,last_name from actor where actor_id = 178;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 178      | LISA       | MONROE    |
+----------+------------+-----------+
1 row in set (0.00 sec)
當前session對actor_id=178的記錄加share mode 的共享鎖：
mysql> select actor_id,first_name,last_name from actor where actor_id = 178lock in share mode;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 178      | LISA       | MONROE    |
+----------+------------+-----------+
1 row in set (0.01 sec)
  
 
其他session仍然可以查詢記錄，並也可以對該記錄加share mode的共享鎖：
mysql> select actor_id,first_name,last_name from actor where actor_id = 178lock in share mode;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 178      | LISA       | MONROE    |
+----------+------------+-----------+
1 row in set (0.01 sec)
當前session對鎖定的記錄進行更新操作，等待鎖：
mysql> update actor set last_name = ‘MONROE T‘ where actor_id = 178;
等待
  
 
其他session也對該記錄進行更新操作，則會導致死鎖退出：
mysql> update actor set last_name = ‘MONROE T‘ where actor_id = 178;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
獲得鎖後，可以成功更新：
mysql> update actor set last_name = ‘MONROE T‘ where actor_id = 178;
Query OK, 1 row affected (17.67 sec)
Rows matched: 1  Changed: 1  Warnings: 0
  
    當使用SELECT...FOR UPDATE加鎖後再更新記錄，出現如下表所示的情況。
 InnoDB存儲引擎的排他鎖例子
session_1 session_2
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> select actor_id,first_name,last_name from actor where actor_id = 178;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 178      | LISA       | MONROE    |
+----------+------------+-----------+
1 row in set (0.00 sec)
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> select actor_id,first_name,last_name from actor where actor_id = 178;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 178      | LISA       | MONROE    |
+----------+------------+-----------+
1 row in set (0.00 sec)
當前session對actor_id=178的記錄加for update的排它鎖：
mysql> select actor_id,first_name,last_name from actor where actor_id = 178 for update;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 178      | LISA       | MONROE    |
+----------+------------+-----------+
1 row in set (0.00 sec)
  
 
其他session可以查詢該記錄，但是不能對該記錄加共享鎖，會等待獲得鎖：
mysql> select actor_id,first_name,last_name from actor where actor_id = 178;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 178      | LISA       | MONROE    |
+----------+------------+-----------+
1 row in set (0.00 sec)
mysql> select actor_id,first_name,last_name from actor where actor_id = 178 for update;
等待
當前session可以對鎖定的記錄進行更新操作，更新後釋放鎖：
mysql> update actor set last_name = ‘MONROE T‘ where actor_id = 178;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
mysql> commit;
Query OK, 0 rows affected (0.01 sec)
  
 
其他session獲得鎖，得到其他session提交的記錄：
mysql> select actor_id,first_name,last_name from actor where actor_id = 178 for update;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 178      | LISA       | MONROE T  |
+----------+------------+-----------+
1 row in set (9.59 sec)
 
InnoDB行鎖實現方式
InnoDB行鎖是通過給索引上的索引項加鎖來實現的，這一點MySQL與Oracle不同，後者是通過在數據塊中對相應數據行加鎖來實現的。InnoDB這種行鎖實現特點意味着：只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖！
在實際應用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導致大量的鎖衝突，從而影響併發性能。下面通過一些實際例子來加以說明。
（1）在不通過索引條件查詢的時候，InnoDB確實使用的是表鎖，而不是行鎖。
在如下所示的例子中，開始tab_no_index表沒有索引：
mysql> create table tab_no_index(id int,name varchar(10)) engine=innodb;
Query OK, 0 rows affected (0.15 sec)
mysql> insert into tab_no_index values(1,‘1‘),(2,‘2‘),(3,‘3‘),(4,‘4‘);
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0
   InnoDB存儲引擎的表在不使用索引時使用表鎖例子
session_1 session_2
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_no_index where id = 1 ;
+------+------+
| id   | name |
+------+------+
| 1    | 1    |
+------+------+
1 row in set (0.00 sec)
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_no_index where id = 2 ;
+------+------+
| id   | name |
+------+------+
| 2    | 2    |
+------+------+
1 row in set (0.00 sec)
mysql> select * from tab_no_index where id = 1 for update;
+------+------+
| id   | name |
+------+------+
| 1    | 1    |
+------+------+
1 row in set (0.00 sec)
  
 
mysql> select * from tab_no_index where id = 2 for update;
等待
在如上表所示的例子中，看起來session_1只給一行加了排他鎖，但session_2在請求其他行的排他鎖時，卻出現了鎖等待！原因就是在沒有索引的情況下，InnoDB只能使用表鎖。當我們給其增加一個索引後，InnoDB就只鎖定了符合條件的行，如下表所示。
創建tab_with_index表，id字段有普通索引：
mysql> create table tab_with_index(id int,name varchar(10)) engine=innodb;
Query OK, 0 rows affected (0.15 sec)
mysql> alter table tab_with_index add index id(id);
Query OK, 4 rows affected (0.24 sec)
Records: 4  Duplicates: 0  Warnings: 0
   InnoDB存儲引擎的表在使用索引時使用行鎖例子
session_1 session_2
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 1 ;
+------+------+
| id   | name |
+------+------+
| 1    | 1    |
+------+------+
1 row in set (0.00 sec)
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 2 ;
+------+------+
| id   | name |
+------+------+
| 2    | 2    |
+------+------+
1 row in set (0.00 sec)
mysql> select * from tab_with_index where id = 1 for update;
+------+------+
| id   | name |
+------+------+
| 1    | 1    |
+------+------+
1 row in set (0.00 sec)
  
 
mysql> select * from tab_with_index where id = 2 for update;
+------+------+
| id   | name |
+------+------+
| 2    | 2    |
+------+------+
1 row in set (0.00 sec)
（2）由於MySQL的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果是使用相同的索引鍵，是會出現鎖衝突的。應用設計的時候要注意這一點。
在如下表所示的例子中，表tab_with_index的id字段有索引，name字段沒有索引：
mysql> alter table tab_with_index drop index name;
Query OK, 4 rows affected (0.22 sec)
Records: 4  Duplicates: 0  Warnings: 0
mysql> insert into tab_with_index  values(1,‘4‘);
Query OK, 1 row affected (0.00 sec)
mysql> select * from tab_with_index where id = 1;
+------+------+
| id   | name |
+------+------+
| 1    | 1    |
| 1    | 4    |
+------+------+
2 rows in set (0.00 sec)
  InnoDB存儲引擎使用相同索引鍵的阻塞例子       
session_1 session_2
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 1 and name = ‘1‘ for update;
+------+------+
| id   | name |
+------+------+
| 1    | 1    |
+------+------+
1 row in set (0.00 sec)
  
 
雖然session_2訪問的是和session_1不同的記錄，但是因爲使用了相同的索引，所以需要等待鎖：
mysql> select * from tab_with_index where id = 1 and name = ‘4‘ for update;
等待
（3）當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，另外，不論是使用主鍵索引、唯一索引或普通索引，InnoDB都會使用行鎖來對數據加鎖。
在如下表所示的例子中，表tab_with_index的id字段有主鍵索引，name字段有普通索引：
mysql> alter table tab_with_index add index name(name);
Query OK, 5 rows affected (0.23 sec)
Records: 5  Duplicates: 0  Warnings: 0
  InnoDB存儲引擎的表使用不同索引的阻塞例子
session_1 session_2
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 1 for update;
+------+------+
| id   | name |
+------+------+
| 1    | 1    |
| 1    | 4    |
+------+------+
2 rows in set (0.00 sec)
  
 
Session_2使用name的索引訪問記錄，因爲記錄沒有被索引，所以可以獲得鎖：
mysql> select * from tab_with_index where name = ‘2‘ for update;
+------+------+
| id   | name |
+------+------+
| 2    | 2    |
+------+------+
1 row in set (0.00 sec)
 
由於訪問的記錄已經被session_1鎖定，所以等待獲得鎖。：
mysql> select * from tab_with_index where name = ‘4‘ for update;
（4）即便在條件中使用了索引字段，但是否使用索引來檢索數據是由MySQL通過判斷不同執行計劃的代價來決定的，如果MySQL認爲全表掃描效率更高，比如對一些很小的表，它就不會使用索引，這種情況下InnoDB將使用表鎖，而不是行鎖。因此，在分析鎖衝突時，別忘了檢查SQL的執行計劃，以確認是否真正使用了索引。
 
在下面的例子中，檢索值的數據類型與索引字段不同，雖然MySQL能夠進行數據類型轉換，但卻不會使用索引，從而導致InnoDB使用表鎖。通過用explain檢查兩條SQL的執行計劃，我們可以清楚地看到了這一點。
例子中tab_with_index表的name字段有索引，但是name字段是varchar類型的，如果where條件中不是和varchar類型進行比較，則會對name進行類型轉換，而執行的全表掃描。
mysql> alter table tab_no_index add index name(name);
Query OK, 4 rows affected (8.06 sec)
Records: 4  Duplicates: 0  Warnings: 0
mysql> explain select * from tab_with_index where name = 1 \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tab_with_index
         type: ALL
possible_keys: name
          key: NULL
      key_len: NULL
          ref: NULL         rows: 4        Extra: Using where1 row in set (0.00 sec)mysql> explain select * from tab_with_index where name = ‘1‘ \G*************************** 1. row ***************************           id: 1  select_type: SIMPLE        table: tab_with_index         type: refpossible_keys: name          key: name      key_len: 23          ref: const         rows: 1        Extra: Using where1 row in set (0.00 sec) 間隙鎖（Next-Key鎖）當我們用範圍條件而不是相等條件檢索數據，並請求共享或排他鎖時，InnoDB會給符合條件的已有數據記錄的索引項加鎖；對於鍵值在條件範圍內但並不存在的記錄，叫做“間隙（GAP)”，InnoDB也會對這個“間隙”加鎖，這種鎖機制就是所謂的間隙鎖（Next-Key鎖）。舉例來說，假如emp表中只有101條記錄，其empid的值分別是 1,2,...,100,101，下面的SQL：Select * from  emp where empid > 100 for update;是一個範圍條件的檢索，InnoDB不僅會對符合條件的empid值爲101的記錄加鎖，也會對empid大於101（這些記錄並不存在）的“間隙”加鎖。InnoDB使用間隙鎖的目的，一方面是爲了防止幻讀，以滿足相關隔離級別的要求，對於上面的例子，要是不使用間隙鎖，如果其他事務插入了empid大於100的任何記錄，那麼本事務如果再次執行上述語句，就會發生幻讀；另外一方面，是爲了滿足其恢復和複製的需要。有關其恢復和複製對鎖機制的影響，以及不同隔離級別下InnoDB使用間隙鎖的情況，在後續的章節中會做進一步介紹。很顯然，在使用範圍條件檢索並鎖定記錄時，InnoDB這種加鎖機制會阻塞符合條件範圍內鍵值的併發插入，這往往會造成嚴重的鎖等待。因此，在實際應用開發中，尤其是併發插入比較多的應用，我們要儘量優化業務邏輯，儘量使用相等條件來訪問更新數據，避免使用範圍條件。還要特別說明的是，InnoDB除了通過範圍條件加鎖時使用間隙鎖外，如果使用相等條件請求給一個不存在的記錄加鎖，InnoDB也會使用間隙鎖！在如下表所示的例子中，假如emp表中只有101條記錄，其empid的值分別是1,2,......,100,101。               InnoDB存儲引擎的間隙鎖阻塞例子session_1session_2mysql> select @@tx_isolation;+-----------------+| @@tx_isolation  |+-----------------+| REPEATABLE-READ |+-----------------+1 row in set (0.00 sec)mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)mysql> select @@tx_isolation;+-----------------+| @@tx_isolation  |+-----------------+| REPEATABLE-READ |+-----------------+1 row in set (0.00 sec)mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)當前session對不存在的記錄加for update的鎖：mysql> select * from emp where empid = 102 for update;Empty set (0.00 sec)  這時，如果其他session插入empid爲102的記錄（注意：這條記錄並不存在），也會出現鎖等待：mysql>insert into emp(empid,...) values(102,...);阻塞等待Session_1 執行rollback：mysql> rollback;Query OK, 0 rows affected (13.04 sec)  由於其他session_1回退後釋放了Next-Key鎖，當前session可以獲得鎖併成功插入記錄：mysql>insert into emp(empid,...) values(102,...);Query OK, 1 row affected (13.35 sec) 恢復和複製的需要，對InnoDB鎖機制的影響MySQL通過BINLOG錄執行成功的INSERT、UPDATE、DELETE等更新數據的SQL語句，並由此實現MySQL數據庫的恢復和主從複製（可以參見本書“管理篇”的介紹）。MySQL的恢復機制（複製其實就是在Slave Mysql不斷做基於BINLOG的恢復）有以下特點。l  一是MySQL的恢復是SQL語句級的，也就是重新執行BINLOG中的SQL語句。這與Oracle數據庫不同，Oracle是基於數據庫文件塊的。l  二是MySQL的Binlog是按照事務提交的先後順序記錄的，恢復也是按這個順序進行的。這點也與Oralce不同，Oracle是按照系統更新號（System Change Number，SCN）來恢復數據的，每個事務開始時，Oracle都會分配一個全局唯一的SCN，SCN的順序與事務開始的時間順序是一致的。從上面兩點可知，MySQL的恢復機制要求：在一個事務未提交前，其他併發事務不能插入滿足其鎖定條件的任何記錄，也就是不允許出現幻讀，這已經超過了ISO/ANSI SQL92“可重複讀”隔離級別的要求，實際上是要求事務要串行化。這也是許多情況下，InnoDB要用到間隙鎖的原因，比如在用範圍條件更新記錄時，無論在Read Commited或是Repeatable Read隔離級別下，InnoDB都要使用間隙鎖，但這並不是隔離級別要求的，有關InnoDB在不同隔離級別下加鎖的差異在下一小節還會介紹。另外，對於“insert  into target_tab select * from source_tab where ...”和“create  table new_tab ...select ... From  source_tab where ...(CTAS)”這種SQL語句，用戶並沒有對source_tab做任何更新操作，但MySQL對這種SQL語句做了特別處理。先來看如下表的例子。                   CTAS操作給原表加鎖例子session_1session_2mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)mysql> select * from target_tab;Empty set (0.00 sec)mysql> select * from source_tab where name = ‘1‘;+----+------+----+| d1 | name | d2 |+----+------+----+|  4 | 1    |  1 ||  5 | 1    |  1 ||  6 | 1    |  1 ||  7 | 1    |  1 ||  8 | 1    |  1 |+----+------+----+5 rows in set (0.00 sec)mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)mysql> select * from target_tab;Empty set (0.00 sec)mysql> select * from source_tab where name = ‘1‘;+----+------+----+| d1 | name | d2 |+----+------+----+|  4 | 1    |  1 ||  5 | 1    |  1 ||  6 | 1    |  1 ||  7 | 1    |  1 ||  8 | 1    |  1 |+----+------+----+5 rows in set (0.00 sec)mysql> insert into target_tab select d1,name from source_tab where name = ‘1‘;Query OK, 5 rows affected (0.00 sec)Records: 5  Duplicates: 0  Warnings: 0  mysql> update source_tab set name = ‘1‘ where name = ‘8‘;等待commit;  返回結果commit;在上面的例子中，只是簡單地讀 source_tab表的數據，相當於執行一個普通的SELECT語句，用一致性讀就可以了。ORACLE正是這麼做的，它通過MVCC技術實現的多版本數據來實現一致性讀，不需要給source_tab加任何鎖。我們知道InnoDB也實現了多版本數據，對普通的SELECT一致性讀，也不需要加任何鎖；但這裏InnoDB卻給source_tab加了共享鎖，並沒有使用多版本數據一致性讀技術！MySQL爲什麼要這麼做呢？其原因還是爲了保證恢復和複製的正確性。因爲不加鎖的話，如果在上述語句執行過程中，其他事務對source_tab做了更新操作，就可能導致數據恢復的結果錯誤。爲了演示這一點，我們再重複一下前面的例子，不同的是在session_1執行事務前，先將系統變量 innodb_locks_unsafe_for_binlog的值設置爲“on”（其默認值爲off），具體結果如下表所示。                  CTAS操作不給原表加鎖帶來的安全問題例子session_1session_2mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)mysql>set innodb_locks_unsafe_for_binlog=‘on‘Query OK, 0 rows affected (0.00 sec)mysql> select * from target_tab;Empty set (0.00 sec)mysql> select * from source_tab where name = ‘1‘;+----+------+----+| d1 | name | d2 |+----+------+----+|  4 | 1    |  1 ||  5 | 1    |  1 ||  6 | 1    |  1 ||  7 | 1    |  1 ||  8 | 1    |  1 |+----+------+----+5 rows in set (0.00 sec)mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)mysql> select * from target_tab;Empty set (0.00 sec)mysql> select * from source_tab where name = ‘1‘;+----+------+----+| d1 | name | d2 |+----+------+----+|  4 | 1    |  1 ||  5 | 1    |  1 ||  6 | 1    |  1 ||  7 | 1    |  1 ||  8 | 1    |  1 |+----+------+----+5 rows in set (0.00 sec)mysql> insert into target_tab select d1,name from source_tab where name = ‘1‘;Query OK, 5 rows affected (0.00 sec)Records: 5  Duplicates: 0  Warnings: 0  session_1未提交，可以對session_1的select的記錄進行更新操作。mysql> update source_tab set name = ‘8‘ where name = ‘1‘;Query OK, 5 rows affected (0.00 sec)Rows matched: 5  Changed: 5  Warnings: 0mysql> select * from source_tab where name = ‘8‘;+----+------+----+| d1 | name | d2 |+----+------+----+|  4 | 8    |  1 ||  5 | 8    |  1 ||  6 | 8    |  1 ||  7 | 8    |  1 ||  8 | 8    |  1 |+----+------+----+5 rows in set (0.00 sec) 更新操作先提交mysql> commit;Query OK, 0 rows affected (0.05 sec)插入操作後提交mysql> commit;Query OK, 0 rows affected (0.07 sec) 此時查看數據，target_tab中可以插入source_tab更新前的結果，這符合應用邏輯：mysql> select * from source_tab where name = ‘8‘;+----+------+----+| d1 | name | d2 |+----+------+----+|  4 | 8    |  1 ||  5 | 8    |  1 ||  6 | 8    |  1 ||  7 | 8    |  1 ||  8 | 8    |  1 |+----+------+----+5 rows in set (0.00 sec)mysql> select * from target_tab;+------+------+| id   | name |+------+------+| 4    | 1.00 || 5    | 1.00 || 6    | 1.00 || 7    | 1.00 || 8    | 1.00 |+------+------+5 rows in set (0.00 sec)mysql> select * from tt1 where name = ‘1‘;Empty set (0.00 sec)mysql> select * from source_tab where name = ‘8‘;+----+------+----+| d1 | name | d2 |+----+------+----+|  4 | 8    |  1 ||  5 | 8    |  1 ||  6 | 8    |  1 ||  7 | 8    |  1 ||  8 | 8    |  1 |+----+------+----+5 rows in set (0.00 sec)mysql> select * from target_tab;+------+------+| id   | name |+------+------+| 4    | 1.00 || 5    | 1.00 || 6    | 1.00 || 7    | 1.00 || 8    | 1.00 |+------+------+5 rows in set (0.00 sec)從上可見，設置系統變量innodb_locks_unsafe_for_binlog的值爲“on”後，InnoDB不再對source_tab加鎖，結果也符合應用邏輯，但是如果分析BINLOG的內容：......SET TIMESTAMP=1169175130;BEGIN;# at 274#070119 10:51:57 server id 1  end_log_pos 105   Query   thread_id=1     exec_time=0     error_code=0SET TIMESTAMP=1169175117;update source_tab set name = ‘8‘ where name = ‘1‘;# at 379#070119 10:52:10 server id 1  end_log_pos 406   Xid = 5COMMIT;# at 406#070119 10:52:14 server id 1  end_log_pos 474   Query   thread_id=2     exec_time=0     error_code=0SET TIMESTAMP=1169175134;BEGIN;# at 474#070119 10:51:29 server id 1  end_log_pos 119   Query   thread_id=2     exec_time=0     error_code=0SET TIMESTAMP=1169175089;insert into target_tab select d1,name from source_tab where name = ‘1‘;# at 593#070119 10:52:14 server id 1  end_log_pos 620   Xid = 7COMMIT;......    可以發現，在BINLOG中，更新操作的位置在INSERT...SELECT之前，如果使用這個BINLOG進行數據庫恢復，恢復的結果與實際的應用邏輯不符；如果進行復制，就會導致主從數據庫不一致！通過上面的例子，我們就不難理解爲什麼MySQL在處理“Insert  into target_tab select * from source_tab where ...”和“create  table new_tab ...select ... From  source_tab where ...”時要給source_tab加鎖，而不是使用對併發影響最小的多版本數據來實現一致性讀。還要特別說明的是，如果上述語句的SELECT是範圍條件，InnoDB還會給源表加間隙鎖（Next-Lock）。因此，INSERT...SELECT...和 CREATE TABLE...SELECT...語句，可能會阻止對源表的併發更新，造成對源表鎖的等待。如果查詢比較複雜的話，會造成嚴重的性能問題，我們在應用中應儘量避免使用。實際上，MySQL將這種SQL叫作不確定（non-deterministic）的SQL，不推薦使用。如果應用中一定要用這種SQL來實現業務邏輯，又不希望對源表的併發更新產生影響，可以採取以下兩種措施：一是採取上面示例中的做法，將innodb_locks_unsafe_for_binlog的值設置爲“on”，強制MySQL使用多版本數據一致性讀。但付出的代價是可能無法用binlog正確地恢復或複製數據，因此，不推薦使用這種方式。二是通過使用“select * from source_tab ... Into outfile”和“load data infile ...”語句組合來間接實現，採用這種方式MySQL不會給source_tab加鎖。InnoDB在不同隔離級別下的一致性讀及鎖的差異前面講過，鎖和多版本數據是InnoDB實現一致性讀和ISO/ANSI SQL92隔離級別的手段，因此，在不同的隔離級別下，InnoDB處理SQL時採用的一致性讀策略和需要的鎖是不同的。同時，數據恢復和複製機制的特點，也對一些SQL的一致性讀策略和鎖策略有很大影響。將這些特性歸納成如下表所示的內容，以便讀者查閱。                                          InnoDB存儲引擎中不同SQL在不同隔離級別下鎖比較隔離級別        一致性讀和鎖SQLRead UncommitedRead CommitedRepeatable ReadSerializableSQL條件    select相等None locksConsisten read/None lockConsisten read/None lockShare locks範圍None locksConsisten read/None lockConsisten read/None lockShare Next-Keyupdate相等exclusive locksexclusive locksexclusive locksExclusive locks範圍exclusive next-keyexclusive next-keyexclusive next-keyexclusive next-keyInsertN/Aexclusive locksexclusive locksexclusive locksexclusive locksreplace無鍵衝突exclusive locksexclusive locksexclusive locksexclusive locks鍵衝突exclusive next-keyexclusive next-keyexclusive next-keyexclusive next-keydelete相等exclusive locksexclusive locksexclusive locksexclusive locks範圍exclusive next-keyexclusive next-keyexclusive next-keyexclusive next-keySelect ... from ... Lock in share mode相等Share locksShare locksShare locksShare locks範圍Share locksShare locksShare Next-KeyShare Next-KeySelect * from ... For update相等exclusive locksexclusive locksexclusive locksexclusive locks範圍exclusive locksShare locksexclusive next-keyexclusive next-keyInsert into ... Select ...（指源表鎖）innodb_locks_unsafe_for_binlog=offShare Next-KeyShare Next-KeyShare Next-KeyShare Next-Keyinnodb_locks_unsafe_for_binlog=onNone locksConsisten read/None lockConsisten read/None lockShare Next-Keycreate table ... Select ...（指源表鎖）innodb_locks_unsafe_for_binlog=offShare Next-KeyShare Next-KeyShare Next-KeyShare Next-Keyinnodb_locks_unsafe_for_binlog=onNone locksConsisten read/None lockConsisten read/None lockShare Next-Key從上表可以看出：對於許多SQL，隔離級別越高，InnoDB給記錄集加的鎖就越嚴格（尤其是使用範圍條件的時候），產生鎖衝突的可能性也就越高，從而對併發性事務處理性能的影響也就越大。因此，我們在應用中，應該儘量使用較低的隔離級別，以減少鎖爭用的機率。實際上，通過優化事務邏輯，大部分應用使用Read Commited隔離級別就足夠了。對於一些確實需要更高隔離級別的事務，可以通過在程序中執行SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ或SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE動態改變隔離級別的方式滿足需求。 什麼時候使用表鎖對於InnoDB表，在絕大部分情況下都應該使用行級鎖，因爲事務和行鎖往往是我們之所以選擇InnoDB表的理由。但在個別特殊事務中，也可以考慮使用表級鎖。第一種情況是：事務需要更新大部分或全部數據，表又比較大，如果使用默認的行鎖，不僅這個事務執行效率低，而且可能造成其他事務長時間鎖等待和鎖衝突，這種情況下可以考慮使用表鎖來提高該事務的執行速度。第二種情況是：事務涉及多個表，比較複雜，很可能引起死鎖，造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表，從而避免死鎖、減少數據庫因事務回滾帶來的開銷。當然，應用中這兩種事務不能太多，否則，就應該考慮使用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讀，可以按如下做：SET AUTOCOMMIT=0;LOCK TABLES t1 WRITE, t2 READ, ...;[do something with tables t1 and t2 here];COMMIT;UNLOCK TABLES; 關於死鎖上文講過，MyISAM表鎖是deadlock free的，這是因爲MyISAM總是一次獲得所需的全部鎖，要麼全部滿足，要麼等待，因此不會出現死鎖。但在InnoDB中，除單個SQL組成的事務外，鎖是逐步獲得的，這就決定了在InnoDB中發生死鎖是可能的。如下所示的就是一個發生死鎖的例子。 InnoDB存儲引擎中的死鎖例子session_1session_2mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)mysql> select * from table_1 where where id=1 for update;...做一些其他處理...mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)mysql> select * from table_2 where id=1 for update;...select * from table_2 where id =1 for update;因session_2已取得排他鎖，等待做一些其他處理... mysql> select * from table_1 where where id=1 for update;死鎖在上面的例子中，兩個事務都需要獲得對方持有的排他鎖才能繼續完成事務，這種循環鎖等待就是典型的死鎖。發生死鎖後，InnoDB一般都能自動檢測到，並使一個事務釋放鎖並回退，另一個事務獲得鎖，繼續完成事務。但在涉及外部鎖，或涉及表鎖的情況下，InnoDB並不能完全自動檢測到死鎖，這需要通過設置鎖等待超時參數 innodb_lock_wait_timeout來解決。需要說明的是，這個參數並不是只用來解決死鎖問題，在併發訪問比較高的情況下，如果大量事務因無法立即獲得所需的鎖而掛起，會佔用大量計算機資源，造成嚴重性能問題，甚至拖跨數據庫。我們通過設置合適的鎖等待超時閾值，可以避免這種情況發生。通常來說，死鎖都是應用設計的問題，通過調整業務流程、數據庫對象設計、事務大小，以及訪問數據庫的SQL語句，絕大部分死鎖都可以避免。下面就通過實例來介紹幾種避免死鎖的常用方法。（1）在應用中，如果不同的程序會併發存取多個表，應儘量約定以相同的順序來訪問表，這樣可以大大降低產生死鎖的機會。在下面的例子中，由於兩個session訪問兩個表的順序不同，發生死鎖的機會就非常高！但如果以相同的順序來訪問，死鎖就可以避免。       InnoDB存儲引擎中表順序造成的死鎖例子session_1session_2mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select first_name,last_name from actor where actor_id = 1 for update;+------------+-----------+| first_name | last_name |+------------+-----------+| PENELOPE   | GUINESS   |+------------+-----------+1 row in set (0.00 sec)  mysql> insert into country (country_id,country) values(110,‘Test‘);Query OK, 1 row affected (0.00 sec)mysql>  insert into country (country_id,country) values(110,‘Test‘);等待  mysql> select first_name,last_name from actor where actor_id = 1 for update;+------------+-----------+| first_name | last_name |+------------+-----------+| PENELOPE   | GUINESS   |+------------+-----------+1 row in set (0.00 sec)mysql>  insert into country (country_id,country) values(110,‘Test‘);ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction （2）在程序以批量方式處理數據的時候，如果事先對數據排序，保證每個線程按固定的順序來處理記錄，也可以大大降低出現死鎖的可能。       InnoDB存儲引擎中表數據操作順序不一致造成的死鎖例子session_1session_2mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select first_name,last_name from actor where actor_id = 1 for update;+------------+-----------+| first_name | last_name |+------------+-----------+| PENELOPE   | GUINESS   |+------------+-----------+1 row in set (0.00 sec)  mysql> select first_name,last_name from actor where actor_id = 3 for update;+------------+-----------+| first_name | last_name |+------------+-----------+| ED         | CHASE     |+------------+-----------+1 row in set (0.00 sec)mysql> select first_name,last_name from actor where actor_id = 3 for update;等待  mysql> select first_name,last_name from actor where actor_id = 1 for update;ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transactionmysql> select first_name,last_name from actor where actor_id = 3 for update;+------------+-----------+| first_name | last_name |+------------+-----------+| ED         | CHASE     |+------------+-----------+1 row in set (4.71 sec) （3）在事務中，如果要更新記錄，應該直接申請足夠級別的鎖，即排他鎖，而不應先申請共享鎖，更新時再申請排他鎖，因爲當用戶申請排他鎖時，其他事務可能又已經獲得了相同記錄的共享鎖，從而造成鎖衝突，甚至死鎖。       （4）前面講過，在REPEATABLE-READ隔離級別下，如果兩個線程同時對相同條件記錄用SELECT...FOR UPDATE加排他鎖，在沒有符合該條件記錄情況下，兩個線程都會加鎖成功。程序發現記錄尚不存在，就試圖插入一條新記錄，如果兩個線程都這麼做，就會出現死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可避免問題，如下所示。  InnoDB存儲引擎中隔離級別引起的死鎖例子1session_1session_2mysql> select @@tx_isolation;+-----------------+| @@tx_isolation  |+-----------------+| REPEATABLE-READ |+-----------------+1 row in set (0.00 sec)mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)mysql> select @@tx_isolation;+-----------------+| @@tx_isolation  |+-----------------+| REPEATABLE-READ |+-----------------+1 row in set (0.00 sec)mysql> set autocommit = 0;Query OK, 0 rows affected (0.00 sec)當前session對不存在的記錄加for update的鎖：mysql> select actor_id,first_name,last_name from actor where actor_id = 201 for update;Empty set (0.00 sec)  其他session也可以對不存在的記錄加for update的鎖：mysql> select actor_id,first_name,last_name from actor where actor_id = 201 for update;Empty set (0.00 sec)因爲其他session也對該記錄加了鎖，所以當前的插入會等待：mysql> insert into actor (actor_id , first_name , last_name) values(201,‘Lisa‘,‘Tom‘);等待  因爲其他session已經對記錄進行了更新，這時候再插入記錄就會提示死鎖並退出：mysql> insert into actor (actor_id, first_name , last_name) values(201,‘Lisa‘,‘Tom‘);ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction由於其他session已經退出，當前session可以獲得鎖併成功插入記錄：mysql> insert into actor (actor_id , first_name , last_name) values(201,‘Lisa‘,‘Tom‘);Query OK, 1 row affected (13.35 sec) （5）當隔離級別爲READ COMMITTED時，如果兩個線程都先執行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個線程能插入成功，另一個線程會出現鎖等待，當第1個線程提交後，第2個線程會因主鍵重出錯，但雖然這個線程出錯了，卻會獲得一個排他鎖！這時如果有第3個線程又來申請排他鎖，也會出現死鎖。對於這種情況，可以直接做插入操作，然後再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執行ROLLBACK釋放獲得的排他鎖，如下所示。   InnoDB存儲引擎中隔離級別引起的死鎖例子2session_1session_2session_3mysql> select @@tx_isolation;+----------------+| @@tx_isolation |+----------------+| READ-COMMITTED |+----------------+1 row in set (0.00 sec)mysql> set autocommit=0;Query OK, 0 rows affected (0.01 sec)mysql> select @@tx_isolation;+----------------+| @@tx_isolation |+----------------+| READ-COMMITTED |+----------------+1 row in set (0.00 sec)mysql> set autocommit=0;Query OK, 0 rows affected (0.01 sec)mysql> select @@tx_isolation;+----------------+| @@tx_isolation |+----------------+| READ-COMMITTED |+----------------+1 row in set (0.00 sec)mysql> set autocommit=0;Query OK, 0 rows affected (0.01 sec)Session_1獲得for update的共享鎖：mysql> select actor_id, first_name,last_name from actor where actor_id = 201 for update;Empty set (0.00 sec)由於記錄不存在，session_2也可以獲得for update的共享鎖：mysql> select actor_id, first_name,last_name from actor where actor_id = 201 for update;Empty set (0.00 sec) Session_1可以成功插入記錄：mysql> insert into actor (actor_id,first_name,last_name) values(201,‘Lisa‘,‘Tom‘);Query OK, 1 row affected (0.00 sec)   Session_2插入申請等待獲得鎖：mysql> insert into actor (actor_id,first_name,last_name) values(201,‘Lisa‘,‘Tom‘);等待 Session_1成功提交：mysql> commit;Query OK, 0 rows affected (0.04 sec)   Session_2獲得鎖，發現插入記錄主鍵重，這個時候拋出了異常，但是並沒有釋放共享鎖：mysql> insert into actor (actor_id,first_name,last_name) values(201,‘Lisa‘,‘Tom‘);ERROR 1062 (23000): Duplicate entry ‘201‘ for key ‘PRIMARY‘   Session_3申請獲得共享鎖，因爲session_2已經鎖定該記錄，所以session_3需要等待：mysql> select actor_id, first_name,last_name from actor where actor_id = 201 for update;等待 這個時候，如果session_2直接對記錄進行更新操作，則會拋出死鎖的異常：mysql> update actor set last_name=‘Lan‘ where actor_id = 201;ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction   Session_2釋放鎖後，session_3獲得鎖：mysql> select first_name, last_name from actor where actor_id = 201 for update;+------------+-----------+| first_name | last_name |+------------+-----------+| Lisa       | Tom       |+------------+-----------+1 row in set (31.12 sec)儘管通過上面介紹的設計和SQL優化等措施，可以大大減少死鎖，但死鎖很難完全避免。因此，在程序設計中總是捕獲並處理死鎖異常是一個很好的編程習慣。如果出現死鎖，可以用SHOW INNODB STATUS命令來確定最後一個死鎖產生的原因。返回結果中包括死鎖相關事務的詳細信息，如引發死鎖的SQL語句，事務已經獲得的鎖，正在等待什麼鎖，以及被回滾的事務等。據此可以分析死鎖產生的原因和改進措施。下面是一段SHOW INNODB STATUS輸出的樣例：mysql> show innodb status \G…….------------------------LATEST DETECTED DEADLOCK------------------------070710 14:05:16*** (1) TRANSACTION:TRANSACTION 0 117470078, ACTIVE 117 sec, process no 1468, OS thread id 1197328736 insertingmysql tables in use 1, locked 1LOCK WAIT 5 lock struct(s), heap size 1216MySQL thread id 7521657, query id 673468054 localhost root updateinsert into country (country_id,country) values(110,‘Test‘)………*** (2) TRANSACTION:TRANSACTION 0 117470079, ACTIVE 39 sec, process no 1468, OS thread id 1164048736 starting index read, thread declared inside InnoDB 500mysql tables in use 1, locked 14 lock struct(s), heap size 1216, undo log entries 1MySQL thread id 7521664, query id 673468058 localhost root statisticsselect first_name,last_name from actor where actor_id = 1 for update*** (2) HOLDS THE LOCK(S):………*** (2) WAITING FOR THIS LOCK TO BE GRANTED:………*** WE ROLL BACK TRANSACTION (1)……
一位失去夢想變成鹹魚的乘客
發佈了2 篇原創文章 · 獲贊 22 · 訪問量 4萬+
私信 關注
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

java代碼加載的順序

今天小G,寫下java class加載順序圖，具體如下畫的圖，簡單好記比較

a372663325 2020-07-07 18:09:01

java的垃圾收集器與內存分配策略--兼具算法理論與java實現

java的垃圾收集器與內存分配策略 垃圾收集需要完成的三件事情 哪些內存需要回收 如何回收 什麼時候回收 垃圾收集針對的java內存區域 程序計數器、虛擬機棧、本地方法棧三個內存區域爲線程私有，線程結束時內存會回收，內存的分配

jason_mai 2020-07-06 20:57:17

JAVA初級工程師面試36問(完結)

第三十一問:   說一下線程中sleep()和wait()區別?           1 . sleep（）是讓正在執行的線程主動讓出CPU，當時間到了，在回到自己的線程讓程序運行。但是它並沒有釋放同步資源鎖只是讓出。        

努力前行的小coder 2020-07-06 19:11:49

Java複習之Java深入解析五（包裝器類型的緩存、嵌套類）

1.Java中的八種基本數據類型不是對象，之所以這樣設計，是因爲其使用方便，效率高於對象類型。但是集合類並不支持對基本數據類型的操作。因此就引入了包裝器類。在JDK1.5之後加入了自動拆裝箱機制。裝箱時調用valueOf方法，這是

Hello_1024 2020-07-06 03:53:24

爲什麼需要Java反射？

目錄   什麼是反射？ 反射的實現原理 反射的使用 爲什麼需要反射？（反射的作用/應用場景） 反射的缺點 什麼是反射？ JAVA反射機制是在運行狀態中，對於任意一個類，都能夠知道這個類的所有屬性和方法；對於任意一個對象，都能夠調用它的任意

tongdanping 2020-07-05 22:02:15

Hibernate和Ibatis的區別

一、Hibernate簡介 hibernate是一個開放源代碼的對象關係映射框架，它對JDBC進行了非常輕量級的對象封裝，使得Java程序員可以隨心所欲的使用對象編程思維來操縱數據庫。Hibernate可以應用在任何使用JDBC的場合，既

一位失去梦想变成咸鱼的乘客 2020-07-05 19:02:20

Java基礎面試題之++i / ++i

請寫出下列程序的運行結果：  public class Main { public static void main(String[] args) { int i = 3; i *= ++i; System.out

ni的学长 2020-07-04 15:06:40

java面試常問系列之HashMap詳細源碼分析。

HashMap源碼分析 hashmap一直都是面試的高頻問題。這次讓我們一起徹底幹掉它，以後再也不怕面試官問這個問題了。 首先我們先對這個方法的文檔閱讀一下，下面做個簡單大概的翻譯，先提前瞭解一下hashmap。 那麼，我們再來

请叫我刀刀啊 2020-07-04 06:24:52

java求職面試題彙總（持續更新）

一、華爲武漢研究所（OD模式） 總共有好幾輪：機考-性格測試-視頻技術面試-HR面試-部門負責人面試。 1、機考 總共兩道編碼題，只要一道題目通過率百分之百基本就沒有問題了。題目基本都是牛客網上的編程題，難度一般，不是很高。具體題

请叫我刀刀啊 2020-07-04 06:24:52

java VisualVM 遠程連接linux的tomcat

       白天看了看如何VisualVM如何遠程連接到linux的tomcat上，進行一般的jvm的監控，真不容易啊，白天搞了好大一陣子都沒有搞定，晚上一小會就搞定了，總結原因還是因爲之前找的那個的如何連接的文章寫的不好，真是誤導大衆

超越自己看到的 2020-07-02 01:55:36

記錄面試中的一個有意思的問題

  總算到了我在一個地方呆膩的時候了，打算在2018年3月準備一次新的開始，辭職找工作了，今天去一個我一直符合我選擇標準的公司，今天去面試，其實吧我對

超越自己看到的 2020-07-02 01:55:25

java面試---java基礎+容器

1、jdk和jre有什麼區別？ jdk java開發工具 jre java運行環境 jdk包含jre、java編譯工具javac及java程序調試及分析工具。 2、==和equals（）區別 ==是引用比較 equals是值比較 3、兩個

lupa1521 2020-07-01 14:44:49

【Java面試題】搞定 BAT 的 Java 技術面試，集合詳解篇（上）

先來看看集合的繼承關係圖，如下圖所示：   其中： 外框爲虛線的表示接口，邊框爲實線的表示類； 箭頭爲虛線的表示實現了接口，箭頭爲實線的表示繼承了類。 爲了方便理解，我隱藏了一些與本文內容無關的信息，隱藏的這些內容會在後面的章節中進行詳

架构师修炼 2020-07-01 14:30:56

Spring 核心知識講解，太簡單啦！

Spring Framework 簡稱 Spring，是 Java 開發中最常用的框架，地位僅次於 Java API，就連近幾年比較流行的微服務框架 SpringBoot，也是基於 Spring 實現的，SpringBoot 的誕生是爲了

架构师修炼 2020-07-01 14:30:55

Java 集合就這麼簡單-附面試題

集合有兩個大接口：Collection 和 Map，本文重點來講解集合中另一個常用的集合類型 Map。 以下是 Map 的繼承關係圖： Map 簡介 Map 常用的實現類如下： Hashtable：Java 早期提供的一個哈希表實現，

架构师修炼 2020-07-01 14:30:55