一、隔離級別：
數據庫事務的隔離級別有4個，由低到高依次爲Read uncommitted、Read committed、Repeatable read、Serializable，這四個級別可以逐個解決髒讀、不可重複讀、幻讀這幾類問題。
１. ISOLATION_READ_UNCOMMITTED：這是事務最低的隔離級別，它充許令外一個事務可以看到這個事務未提交的數據。
這種隔離級別會產生髒讀，不可重複讀和幻像讀。
２. ISOLATION_READ_COMMITTED：保證一個事務修改的數據提交後才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的數據
３. ISOLATION_REPEATABLE_READ：這種事務隔離級別可以防止髒讀，不可重複讀。但是可能出現幻像讀。
它除了保證一個事務不能讀取另一個事務未提交的數據外，還保證了避免下面的情況產生(不可重複讀)。
４. ISOLATION_SERIALIZABLE：這是花費最高代價但是最可靠的事務隔離級別。事務被處理爲順序執行。
除了防止髒讀，不可重複讀外，還避免了幻像讀。
我們使用 test 數據庫，新建 tx 表：－－－ＭｙＳＱＬ數據庫
第1級別：Read Uncommitted(讀取未提交內容)
(1)所有事務都可以看到其他未提交事務的執行結果
(2)本隔離級別很少用於實際應用，因爲它的性能也不比其他級別好多少
(3)該級別引發的問題是——髒讀(Dirty Read)：讀取到了未提交的數據
#首先，修改隔離級別 set tx_isolation='READ-UNCOMMITTED'; select @@tx_isolation; +------------------+ | @@tx_isolation | +------------------+ | READ-UNCOMMITTED | +------------------+
#事務A：啓動一個事務
start transaction;
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
±-----±-----+
#事務B：也啓動一個事務(那麼兩個事務交叉了)
在事務B中執行更新語句，且不提交
start transaction;
update tx set num=10 where id=1;
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
±-----±-----+
#事務A：那麼這時候事務A能看到這個更新了的數據嗎?
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 10 | —>可以看到！說明我們讀到了事務B還沒有提交的數據
| 2 | 2 |
| 3 | 3 |
±-----±-----+
#事務B：事務B回滾,仍然未提交
rollback;
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
±-----±-----+
#事務A：在事務A裏面看到的也是B沒有提交的數據
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 1 | —>髒讀意味着我在這個事務中(A中)，事務B雖然沒有提交，但它任何一條數據變化，我都可以看到！
| 2 | 2 |
| 3 | 3 |
±-----±-----+
第2級別：Read Committed(讀取提交內容)
(1)這是大多數數據庫系統的默認隔離級別（但不是MySQL默認的）
(2)它滿足了隔離的簡單定義：一個事務只能看見已經提交事務所做的改變
(3)這種隔離級別出現的問題是——不可重複讀(Nonrepeatable Read)：不可重複讀意味着我們在同一個事務中執行完全相同的select語句時可能看到不一樣的結果。
|——>導致這種情況的原因可能有：(1)有一個交叉的事務有新的commit，導致了數據的改變;(2)一個數據庫被多個實例操作時,同一事務的其他實例在該實例處理其間可能會有新的commit
#首先修改隔離級別 set tx_isolation='read-committed'; select @@tx_isolation; +----------------+ | @@tx_isolation | +----------------+ | READ-COMMITTED | +----------------+
#事務A：啓動一個事務
start transaction;
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
±-----±-----+
#事務B：也啓動一個事務(那麼兩個事務交叉了)
在這事務中更新數據，且未提交
start transaction;
update tx set num=10 where id=1;
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
±-----±-----+
#事務A：這個時候我們在事務A中能看到數據的變化嗎?
select * from tx; --------------->
±-----±-----+ |
| id | num | |
±-----±-----+ |
| 1 | 1 |—>並不能看到！ |
| 2 | 2 | |
| 3 | 3 | |
±-----±-----+ |——>相同的select語句，結果卻不一樣
|
#事務B：如果提交了事務B呢? |
commit; |
|
#事務A: |
select * from tx; --------------->
±-----±-----+
| id | num |
±-----±-----+
| 1 | 10 |—>因爲事務B已經提交了，所以在A中我們看到了數據變化
| 2 | 2 |
| 3 | 3 |
±-----±-----+
第3級別：Repeatable Read(可重讀)
(1)這是MySQL的默認事務隔離級別
(2)它確保同一事務的多個實例在併發讀取數據時，會看到同樣的數據行
(3)此級別可能出現的問題——幻讀(Phantom Read)：當用戶讀取某一範圍的數據行時，另一個事務又在該範圍內插入了新行，當用戶再讀取該範圍的數據行時，會發現有新的“幻影” 行
(4)InnoDB和Falcon存儲引擎通過多版本併發控制(MVCC，Multiversion Concurrency Control)機制解決了該問題
#首先，更改隔離級別 set tx_isolation='repeatable-read'; select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ | +-----------------+
#事務A：啓動一個事務
start transaction;
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
±-----±-----+
#事務B：開啓一個新事務(那麼這兩個事務交叉了)
在事務B中更新數據，並提交
start transaction;
update tx set num=10 where id=1;
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
±-----±-----+
commit;
#事務A：這時候即使事務B已經提交了,但A能不能看到數據變化？
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 1 | —>還是看不到的！(這個級別2不一樣，也說明級別3解決了不可重複讀問題)
| 2 | 2 |
| 3 | 3 |
±-----±-----+
#事務A：只有當事務A也提交了，它才能夠看到數據變化
commit;
select * from tx;
±-----±-----+
| id | num |
±-----±-----+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
±-----±-----+
第4級別：Serializable(可串行化)
(1)這是最高的隔離級別
(2)它通過強制事務排序，使之不可能相互衝突，從而解決幻讀問題。簡言之,它是在每個讀的數據行上加上共享鎖。
(3)在這個級別，可能導致大量的超時現象和鎖競爭
#首先修改隔離界別 set tx_isolation='serializable'; select @@tx_isolation; +----------------+ | @@tx_isolation | +----------------+ | SERIALIZABLE | +----------------+
#事務A：開啓一個新事務
start transaction;
#事務B：在A沒有commit之前，這個交叉事務是不能更改數據的
start transaction;
insert tx values(‘4’,‘4’);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
update tx set num=10 where id=1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
二、傳播行爲
1、PROPAGATION_REQUIRED：如果當前沒有事務，就創建一個新事務，如果當前存在事務，就加入該事務，該設置是最常用的設置。
2、PROPAGATION_SUPPORTS：支持當前事務，如果當前存在事務，就加入該事務，如果當前不存在事務，就以非事務執行。‘
3、PROPAGATION_MANDATORY：支持當前事務，如果當前存在事務，就加入該事務，如果當前不存在事務，就拋出異常。
4、PROPAGATION_REQUIRES_NEW：創建新事務，無論當前存不存在事務，都創建新事務。
5、PROPAGATION_NOT_SUPPORTED：以非事務方式執行操作，如果當前存在事務，就把當前事務掛起。
6、PROPAGATION_NEVER：以非事務方式執行，如果當前存在事務，則拋出異常。
7、PROPAGATION_NESTED：如果當前存在事務，則在嵌套事務內執行。如果當前沒有事務，則執行與PROPAGATION_REQUIRED類似的操作。