InnoDB行鎖和表鎖的分析
- InnoDB行鎖是通過給索引上的索引項加鎖來實現的,這一點MySQL與Oracle不同,後者是通過在數據塊中對相應數據行加鎖來實現的。
- InnoDB這種行鎖實現特點意味着:只有通過索引條件檢索數據,InnoDB才使用行級鎖,否則,InnoDB將使用表鎖!
- 在實際應用中,要特別注意InnoDB行鎖的這一特性,不然的話,可能導致大量的鎖衝突,從而影響併發性能。
- 下面通過一些實際例子來加以說明。
- (1)在不通過索引條件查詢的時候,InnoDB使用的是表鎖,而不是行鎖
在如表20-9所示的例子中,開始tab_no_index表沒有索引:
表20-9 InnoDB存儲引擎的表在不使用索引時使用表鎖例子
- session_1
- 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)
- session_2
- 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)
- session_1:
- mysql> select * from tab_no_index where id = 1 for update;
- +------+------+
- | id | name |
- +------+------+
- | 1 | 1 |
- +------+------+
- 1
- session_2:
- mysql> select * from tab_no_index where id=2 for update;
- ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
在如表20-9所示的例子中,看起來session_1只給一行加了排他鎖,但session_2在請求其他行的排他鎖時,卻出現了鎖等待!原因就是在沒有索引的情況下,InnoDB只能使用表鎖。當我們給其增加一個索引後,InnoDB就只鎖定了符合條件的行,如表20-10所示。
創建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
表20-10 InnoDB存儲引擎的表在使用索引時使用行鎖例子
|
(2)由於MySQL的行鎖是針對索引加的鎖,不是針對記錄加的鎖,所以雖然是訪問不同行的記錄,但是如果是使用相同的索引鍵,是會出現鎖衝突的。應用設計的時候要注意這一點。
在如表20-11所示的例子中,表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)
表20-11 InnoDB存儲引擎使用相同索引鍵的阻塞例子
- session_1
- mysql> set autocommit=0;
- Query OK, 0 rows affected (0.00 sec)
- session_2
- mysql> set autocommit=0;
- Query OK, 0 rows affected (0.00 sec)
- session_1
- 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都會使用行鎖來對數據加鎖。
在如表20-12所示的例子中,表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
表20-12 InnoDB存儲引擎的表使用不同索引的阻塞例子
|
(4)即便在條件中使用了索引字段,但是否使用索引來檢索數據是由MySQL通過判斷不同執行計劃的代價來決定的,如果MySQL認爲全表掃描效率更高,比如對一些很小的表,它就不會使用索引,這種情況下InnoDB將使用表鎖,而不是行鎖。因此,在分析鎖衝突時,別忘了檢查SQL的執行計劃,以確認是否真正使用了索引。關於MySQL在什麼情況下不使用索引的詳細討論,參見本章“索引問題”一節的介紹。
在下面的例子中,檢索值的數據類型與索引字段不同,雖然MySQL能夠進行數據類型轉換,但卻不會使用索引,從而導致InnoDB使用表鎖。通過用explain檢查兩條SQL的執行計劃,我們可以清楚地看到了這一點。
例子中tab_with_index表的name字段有索引,但是name字段是varchar類型的,如果where條件中不是和varchar類型進行比較,則會對name進行類型轉換,而執行的全表掃描。
當我們用範圍條件而不是相等條件檢索數據,並請求共享或排他鎖時,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也會使用間隙鎖!
在如表20-13所示的例子中,假如emp表中只有101條記錄,其empid的值分別是1,2,......,100,101。
表20-13 InnoDB存儲引擎的間隙鎖阻塞例子
session_1 | session_2 |
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)
|
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爲201的記錄(注意:這條記錄並不存在),也會出現鎖等待:
mysql>insert into emp(empid,...) values(201,...);
阻塞等待
|
|
Session_1 執行rollback:
mysql> rollback;
Query OK, 0 rows affected (13.04 sec)
|
|
由於其他session_1回退後釋放了Next-Key鎖,當前session可以獲得鎖併成功插入記錄:
mysql>insert into emp(empid,...) values(201,...);
Query OK, 1 row affected (13.35 sec)
|
注:關於Innodb什麼情況下使用行鎖,什麼情況使用表鎖,上面的例子介紹的通俗易通,適合初級DBA學習。原來出自http://brilon.iteye.com/blog/433726,歡迎交流溝通,謝謝!