事務概念

數據庫操作的最小工作單元，是作為單個邏輯工作單元執行的一系列操作，經典的事務場景是轉賬，A(id為3)給B(id為1)轉賬：

update user_account set balance = balance - 1000 where user_id = 3; update user_account set balance = balance + 1000 where user_id = 1;

這兩個sql要保證必須同時成功或同時失敗，否則數據將出現不一致的情況。

mysql中的事務

查看mysql事務開啟狀態：

show variables like 'autocommit'

默認是ON。

mysql中開啟事務

會話級別

set session autocommit = on/off;

這個是對當前會話設置自動提交，對其他會話不起作用，如果設置為off，這時候執行完sql后，當前會話都要手動加上commit才能提交事務。

手動開啟

手動執行sql：

開啟事務：begin / start transaction； 提交或回滾事務：commit / rollback

JDBC編程中：

connection.setAutoCommit（boolean）; connection.commit();

Spring事務AOP編程：

expression=execution（com.gpedu.dao.*.*(..))

mysql中默認是自動提交事務的。也就是在你執行sql語句的時候，它會自動在你sql前邊加上begin或start transaction；在后邊自動加上commit；從而事務就會自動提交。

當手動使用begin或start transaction時，mysql就會取消自動加事務，例如：

begin; update user set name="faith" where id=1；

執行后，數據庫id為1的記錄并不會改變，因為這時候mysql不會自動提交，當手動執行commit之后才會進行提交。

而因為mysql自動提交事務，所以如下兩個sql實際上是在兩個事務中的：

update user_account set balance = balance - 1000 where userID = 3; update user_account set balance = balance +1000 where userID = 1;

那么為了保證原子性，我們需要做如下操作：

begin； update user_account set balance = balance - 1000 where userID = 3; update user_account set balance = balance +1000 where userID = 1; commit；

這樣就把這兩個sql放到一個事務中去了。

在jdbc中將兩個sql放到一個事務中,如下：

connection.setAutoCommit（boolean）; update user_account set balance = balance - 1000 where userID = 3; update user_account set balance = balance +1000 where userID = 1; connection.commit();

Spring事務AOP編程，實際上也是做了手動開啟操作:

expression=execution（com.faith.dao.*.*(..))

這里設置了一個切面，基于這個切面的所有方法都會被攔截，這些方法配置事務的傳播性質，攔截之后，spring會在方法之前加一個切面，設置會話手動提交，例如：

connection.setAutoCommit（boolean）;

然后在方法之后加一個切面，設置會話提交，例如：

connection.commit();

當catch到異常的時候，就執行

connection.rollback();

事務的特性

原子性（Atomicity）

事務是最小的工作單元，事務中的sql要么一起提交成功，要么全部失敗回滾。

一致性（Consistency）

事務中操作的數據及狀態改變是一致的，更新的數據必須完全符合預設的規則，不會因為事務或系統等原因導致狀態的不一致。

隔離性（Isolation）

一個事務所操作的數據在提交之前，對其他事務的可見性設定。如果事務并發且相互不隔離，會導致臟讀、不可重復讀、幻讀等系列問題。

持久性（Durability）

事務所做的修改會永久保存，不會因為系統意外導致數據的丟失。

原子性和一致性是兩個不同的概念。對于原子性來說，如下的兩條語句：

update user_account set balance = balance - 1000 where userID = 3; update user_account set balance = balance +10000 where userID = 1;

只要同時執行成功或失敗就是符合原子性的。

而對于一致性來說是不成立的，因為實際給1轉賬1000，但是1的賬戶上多了10000，不符合轉賬的規則，導致了數據的不一致性。

事務的隔離級別

SQL92 ANSI/ISO標準

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt Read Uncommitted（讀未提交）--未解決任何并發問題，可以讀到其他事務未提交的數據，會導致臟讀（dirty read）。Read Committed（讀已提交）--解決臟讀問題，一個事務開始之后，只能看到己提交的事務所做的修改，但是未解決不可重復讀（nonrepeatable read）。Repeatable Read (可重復讀)--解決不可重復讀問題，在同一個事務中多次讀取同樣的數據結果是一樣的，這種隔離級別未定義解決幻讀的問題。Serializable（串行化）--解決所有問題，最高的隔離級別，通過強制事務的串行執行。

innodb對隔離級別的支持

隔離級別臟讀不可重復讀幻讀

讀未提交	可能	可能	可能
讀已提交	不可能	不可能	可能
可重復讀	不可能	不可能	==不可能==
串行化	不可能	不可能	不可能

在92標準中，可重復讀級別可以不解決幻讀問題，但是innodb存儲引擎的可重復讀解決了幻讀問題。

鎖

鎖用來管理不同事務對共享資源的并發訪問。

表鎖與行鎖：

鎖定粒度：表鎖 > 行鎖表鎖直接鎖定表，行鎖只鎖定一行。加鎖效率：表鎖 > 行鎖直接對表加鎖塊，而行鎖需要在表中找到指定的行記錄。沖突概率：表鎖 > 行鎖，表鎖鎖定的記錄更多，更容易產生沖突。并發性能：表鎖 < 行鎖

InnoDB存儲引擎只有行鎖，沒有表鎖，但它也能實現表鎖的效果，因為它的表鎖是把表中所有的行都鎖一遍，就成了表鎖。這個只是實現了表鎖的效果，但是和真正的表鎖效率相比要低下很多。

innodb的鎖類型

InnoDB默認select語句不加任何鎖類型，但是delete、update、insert 默認會加上X鎖。

innodb共有八種鎖：

共享鎖（行鎖）：Shared Locks排它鎖（行鎖）：Exclusive Locks意向鎖共享鎖（表鎖）：Intention Shared Locks意向鎖排它鎖（表鎖）：Intention Exclusive Locks自增鎖：AUTO-INC Locks關于行鎖的鎖：記錄鎖 Record Locks間隙鎖 Gap Locks臨鍵鎖 Next-key Locks

共享鎖

又稱為讀鎖，簡稱S鎖，多個事務對于同一數據可以共享一把共享鎖，持有共享鎖的事務都能訪問到數據，但是只能讀不能修改。

共享鎖示例：

begin； select * from user WHERE id=1 LOCK IN SHARE MODE;

不執行commit操作，這時候在另一個窗口執行：

select * from user WHERE id=1; update user set name='2' where id=1;

select操作可以查到數據，但是update會被阻塞，直到最開始申請到共享鎖的事務執行commit或rollback來釋放享鎖，之后update才會繼續執行。

排他鎖

又稱為寫鎖，簡稱X鎖，排他鎖不能與其他鎖并存，如一個事務獲取了某條記錄的排他鎖，其他事務就不能再獲取該行的鎖（共享鎖、排他鎖），即不能讀不能寫，只有持有排他鎖的事務才可以對記錄進行讀取和修改(其他事務要讀取數據可來自于快照)。

排它鎖示例：

begin； update user set name='2' where id=1；

不執行commit操作，這時候在另一個窗口執行：

select * from user WHERE id=1 LOCK IN SHARE MODE; update user set name='3' where id=1;

這兩條操作都會被阻塞，直至持有排它鎖的事務commit或rollback之后才能繼續執行。

意向共享鎖(IS)

表示事務準備給數據行加入共享鎖，即一個數據行加共享鎖前必須先取得該表的IS鎖，意向共享鎖之間是可以相互兼容的。

意向排它鎖(IX)

表示事務準備給數據行加入排他鎖，即一個數據行加排他鎖前必須先取得該表的IX鎖，意向排它鎖之間也是可以相互兼容的。

意向鎖(IS 、IX)是InnoDB在數據操作之前自動加的，不需要用戶干預，我們編碼時不需要對意向鎖進行特殊處理。

意向鎖是表級鎖，之間是相互兼容的，也就是說多個持有鎖的線程，可以同時持有意向鎖。比如update id=1，update id=2，他們可以同時持有意向鎖。

意向鎖存在的意義：

只有當事務想去進行鎖表時，意向鎖才會發揮作用，事務會先判斷意向鎖是否存在，如果存在，說明此時肯定有行鎖存在，這時候不能進行表鎖，則可快速返回該表不能啟用表鎖，省略了進入底層掃描全表的數據。

自增鎖

針對自增列自增長的一個特殊的表級別鎖，可以使用如下語句查看自增鎖的模式：

show variables like 'innodb_autoinc_lock_mode';

此參數可取的值有三個：0、1、2，默認取值1。

取值0：傳統方式，串行自增，并且是連續的。這種模式下需要語句執行完成才釋放自增鎖，所以性能最低。例如：1、2、3、4、5、6，沒有人為刪除情況下，表中id字段一定是連續的。

取值1：連續方式，自增的，并且是連續的。當語句申請到自增鎖就釋放自增鎖，自增鎖就可以給其它語句使用，性能會好很多。但因為不會等待語句事務執行完畢就釋放了自增鎖，可能該事務回滾了，所以id可能會出現斷續的情況，例如：1、2、6，8,10

2：交錯方式，多語句插入數據時，有可能自增的序列號和執行先后順不一致，并且中間可能有斷裂。一次分配一批自增值，然后下個語句就再進行分配一批自增值，阻塞很小，性能很高。例如：1、2、3、6、5。

設置為2時，需要確認表是否需要連續的自增值，如果需要，就不要使用這個值。

臨鍵鎖(Next-key locks)

當sql執行按照索引進行檢索，查詢條件為范圍查找(between and、<、>等)并且有數據命中，則此時SQL語句加上的鎖為Next-key locks，鎖住索引范圍為記錄的本區間 + 本區間下一個區間(左開右閉)。

mysql會對記錄自動劃分出區間，如下：

如果為1,2,4,7,10，區間則為（-&,1],(1,2],(2,4],(4,7],(7,10],(10,+&)。劃分區間是依據B+樹節點之間的間隙來劃分的，1和2之間沒有間隙，但是在樹中，是兩個不同的節點，它們之間是有間隙的。

update user set name=1 where id>5 and id<10

上面的sql選中的記錄是id=7，這時候鎖住的區間是(4,7]，(7,10]，(4,7]是本區間，而(7,10]是本區間的下一個區間。

鎖住本區間和相鄰區間就是防止幻讀，例如這里的>5和<9條件，肯定是要鎖定(4,7]，(7,10]區間才能實現的，也就是要鎖住本區間和相鄰區間。

鎖住區間是因為B+樹的特性，如果把這個例子中的id換成age就更好理解了。

因為innodb默認隔離級別是可重復讀，而前邊說了innodb的可重復讀還捎帶解決了幻讀問題，而幻讀問題就是臨鍵鎖配合mvcc一起解決的。

間隙鎖(Gap locks)

當sql執行按照索引進行檢索，查詢條件為范圍查找并且查詢的數據不存在，這時SQL語句加上的鎖即為Gap locks，鎖住索引不存在的區間(左開右開)。

只在可重復讀隔離級別存在是因為innodb的可重復讀解決了幻讀問題。

Record locks

當sql執行按照唯一性(Primary key、Unique key)索引進行檢索，查詢條件為精準等值匹
配且查詢的數據是存在，這時SQL語句加上的鎖即為記錄鎖Record locks，這種情況只針對唯一索引，所以對應的是const或equ_ref級別的查詢。

innodb的行鎖鎖住了哪些內容

得出結論之前先做個測試。例如user表中，id，name，age，create_time字段，id和name有索引，create_time沒有加索引。

測試1

begin； select * from user where id=1;

不執行commit或rollback。然后在其他線程執行：

select * from user where id=1; 阻塞 select * from user where id=2; 非阻塞 select * from user where id=3; 非阻塞

測試2

begin； select * from user where name=‘1’;

不執行commit或rollback。然后在其他線程執行：

select * from user where name=‘1’; 阻塞 select * from user where name=‘2’; 非阻塞 select * from user where name=‘3’; 非阻塞

測試3

begin； select * from user where create_time=1;

不執行commit或rollback。然后在其他線程執行：

select * from user where create_time=1; 阻塞 select * from user where create_time=2; 阻塞 select * from user where create_time=3; 阻塞

結論：InnoDB的行鎖是通過給索引樹中的索引項加鎖來實現的，如果是聚集索引，那么直接鎖住聚集索引的索引項，如果是非聚集索引，那么會鎖住當前索引的索引項，以及對應的聚集索引中的索引項。

也就是說對于非聚集索引，會在兩棵索引樹中分別上鎖。只有通過索引條件進行數據檢索，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖(鎖住索引的所有記錄)。

表鎖是非常耗費性能的，所以要避免表鎖。這種特性可以給平時寫sql帶來一些啟發，例如：

delete from user where create_time；導致表鎖 delete from user where id=1；行鎖；

寫刪改的sql時候，要考慮where條件是否命中了索引，要避免表鎖出現，刪一條記錄，卻導致整張表被鎖住了，這是一件很郁悶的事。

鎖如何解決并發問題

臟讀

加上X鎖可以解決臟讀。

不可重復讀

模擬不可重復讀：

select name from user where id=1;// name='1' update user set name='2' where id=1; // 執行成功 select name from user where id=1;// name='2'

上面兩個select的結果不同，導致了不可重復讀。解決方法是給這兩個select加上S鎖：

select name from user where id=1 LOCK IN SHARE MODE;// name='1' update user set name='2' where id=1; // 阻塞 select name from user where id=1 LOCK IN SHARE MODE;// name='1'

這樣在當前事務執行完畢之前，不可能被其他事務更改值，從而解決了不可重復讀的問題。

幻讀

加臨鍵鎖可以解決幻讀。

死鎖

多個并發事務每個事務都持有鎖，每個事務都需要再繼續持有其他事務持有的鎖，但誰都不釋放自己手中的鎖，產生鎖的循環等待，這就形成了死鎖。

死鎖的避免

類似的業務邏輯以固定的順序訪問表和行。大事務拆小。大事務更傾向于死鎖，如果業務允許，將大事務拆小。在同一個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖概率。降低隔離級別，如果業務允許，將隔離級別調低也是較好的選擇為表添加合理的索引。可以看到如果不走索引將會為表的每一行記錄添加上鎖(或者說是表鎖)，表鎖造成的鎖沖突比行鎖要嚴重的多

總結

以上是生活随笔為你收集整理的Innodb事务和锁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。