事务(Transaction)管理机制
一、總 結
事務是一個最小的不可再分的工作單元。一個事務對應一套完整的業務邏輯。事務管理機制的作用 ——通過保證一系列數據操作過程的完整性,來保障數據的安全性。使用事務的前提條件 —— 數據庫管理系統必須使用支持事務的存儲引擎。MySQL中默認采用InnoDB存儲引擎，默認采用【自動提交模式】來管理事務。事務機制的經典使用場景 —— 處理“銀行賬戶之間的轉賬操作"。事務只和DML語句有關，只有DML語句的出現才存在事務管理。開啟事務管理的標志 ——DML語句的執行。結束事務管理的標志 —— TCL語句的執行。事務管理的四大特性 —— ACID ： 【原子性、一致性、隔離性、持久性】事務之間由低到高的四個隔離級別 —— 【讀未提交、讀已提交、可重復讀、串行化讀】可以把一系列要執行的操作稱為事務。而事務管理就是管理這些操作要么完全執行，要么完全不執行。反映在SQL中就是，事務只和DML語句有關。通常，一個完整的業務需要通過執行批量的DML語句之后，進行統一提交事務，才能達到效果。
二、解 析
(一）銀行轉賬業務的分析
銀行轉賬過程是一個完整的業務，最小的單元，不可再分，也就是說銀行轉賬業務是一個完整的事務。
1） t_act 賬戶表中的數據如下： 2）需求：賬戶“1001”要 轉賬給 “1002”賬戶。 該一系列“轉賬”操作，應當會導致數據庫表中的相關數據發生修改。假設轉賬金額是500元。就應該執行下列兩條DML語句：
update t_act set balance = 1000.0 where actno = ‘act-001’;
update t_act set balance = 500.0 where actno = ‘act-002’;3）分析：- 以上兩條DML語句必須同時成功或者同時失敗，因為它為最小業務單元，不可拆分；- 當第一條DML語句執行成功之后，并不能立馬將底層數據庫中的第一個賬戶的數據修改，應該只是將操作記錄了一下，這個記錄是在內存中完成的。- 當第二條DML語句執行成功之后，底層數據庫文件中的數據需要完成同步。- 若第二條DML語句執行失敗，將清空所有的歷史操作記錄4）技術（機制）： 要完成以上功能，那必須借助mysql數據庫的“事務“機制 transaction。在mysql中并不是所有的數據存儲引擎都支持事務管理的，只有 Innodb數據存儲支持事務管理。且默認采用自動提交事務方式。（即執行DML語句時，默認自動提交事務。)在mysql中，，常用的3種存儲引擎？ 1）myISam （不支持事務） 2）InnoDB （MySql數據庫默認使用是InnoDB存儲引擎。該存儲引擎支持事務。） 3）memory （不支持事務）2. ）一個完整的業務需要批量的DML語句（insert、update、delete）共同完成。比如：銀行賬戶轉賬 業務 從A賬戶向B賬戶轉賬10000 ， 需要執行兩條update語句： update t_act set balance = balance - 10000 where actno = 'act-001'; update t_act set balance = balance + 10000 where actno = 'act-002'; 以上兩條DML語句必須同時成功，或者同時失敗，不允許出現一條成功，一條失敗。 要想保證以上的兩條DML語句同時成功或者同時失敗，那么就需要使用數據庫的“事務機制”。 思考：假設所有的業務都能使用1條DML語句搞定，還需要事務機制嗎？ 該情況不需要使用到事務。 但實際開發中，通常一事務【業務】需要多條DML語句共同聯合完成。事務只和DML語句有關系；當執行DML語句時，其實就是開啟了一個事務。 或者說 只有DML語句（insert/ delete/ update）中才存在事務。 因為它們這三個語句都是和數據庫表當中的“數據”相關的。 以上所描述的批量DML語句共有多少DML語句，這個和業務邏輯有關系。 業務邏輯不同，則DML語句的個數不同。4. ）事務可以保證多個操作的原子性。即，事務的存在就是為了保證數據的完整性，安全性。* 事務可以保證多個操作的原子性：要么全部成功，要么全部失敗。 對于數據庫來說，事務保證批量的DML要么全部成功，要么全部失敗5. ）【TCL】語句是和事務相關的語句 ** rollback 或commit 的執行，標志著事務的結束。4.事務管理？可以把一系列要執行的操作稱為事務。而事務管理就是管理這些操作要么完全執行，要么完全不執行。 經典例子： A要給B轉錢，首先A賬戶錢減少了，但由于數據庫突然斷電，導致無法給B賬戶加錢。 然后由于丟失數據，B不承認收到A的錢； 在這里事務就是確保加錢和減錢兩個都完全執行或完全不執行，如果加錢失敗，那么不會發生減錢。
0)-手動開啟事務管理的命令start transaction這行命令作用是：【start transaction命令的作用】： 在mysql開啟了“自動提交”模式的狀態下，關閉了事務的自動提交機制，對接下來要執行的DML語句進行手動開啟事務管理。 手動開啟事務管理之后，從此mysql不再將DML語句執行出來的結果立即更新到表中。而是會記錄到事務的日志中。只有開發者手動地進行commit提交成功之后，mysql才會將DML執行結果同步到數據庫的表中。1)-事務開啟的標志任何一條DML語句執行，都標志事務的開啟。2)-事務結束的標志commit 或 rollback的執行，都標志著事務的結束。1）事務提交 操作語法：commit ———— 事務成功的結束。 會將所有的DML語句操作記錄 和 底層硬盤文件中數據進行一次同步。2）事務回滾 操作語法：rollback ———— 事務失敗的結束。 會將所有的DML語句操作記錄全部清空。 回滾會清掉開始事務管理之后寫到事務日志中的內容，即恢復到開啟事務管理之前。注意：回退操作只是回退"寫"的內容，對于普通的讀表select語句不能回退。3)-事務管理的意義 保證數據操作的完整性,安全性。4)-注意事項在事務進行過程中，未結束之前，DML語句是不會修改底層數據庫文件中的數據。只是將歷史操作在內存中記錄一下。只有在事務結束，而且是成功結束（提交）的時候，才會修改底層硬盤文件中的數據。只能回滾 insert、delete和update語句，不能回滾select語句（回滾select沒有任何意義)。 對于create、drop、alter這些語句也無法回滾。當 commit 或 rollback 語句執行后，事務會自動關閉（將來的更改會隱含提交）。
(二）事務管理的四大特性
1.原子性（Atomicity）
事務的整個操作是一個整體，不可以分割，要么全部成功，要么全部失敗。 事務是最小的工作單元，不可再分。 只有兩種結果：成功 或 失敗2.一致性（Consistency）
指的是事務操作的前后，數據表中的數據沒有變化。 事務必須保證多條DML語句同時成功或者同時失敗。
3.隔離性（Isolation）
事務之間的操作是相互隔離不受影響的。 事務A與事務B之間具有隔離。一個事務不會影響其他的事務運行。
4.持久性（Durability）
數據一旦提交，不可改變，永久的改變數據表數據 持久性說的是最終數據必須持久化到硬盤文件中，事務才算成功的結束。 只有事務成功提交的情況下，才有持久性。 在事務完成后，該事務對數據庫所做的更改將持久化地保存在數據庫中，事務才算成功的結束。且不會被回滾。
(三）事務管理的提交模式
自動提交模式的狀態用于決定新事務 如何啟動 以及 何時啟動。 自動提交模式的開啟或關閉，可以通過服務器變量AUTOCOMMIT來控制。
1-啟用 自動提交模式
如果自動提交模式被啟用，則單條DML語句將缺省地開始一個新的事務。 如果該語句執行成功，事務將自動提交，并永久地保存該語句的執行結果。 如果語句執行失敗，事務將自動回滾，并取消該語句的執行結果。 在自動提交模式下，仍可使用start transaction語句來顯式地啟動事務。這時，一個事務仍可包含多條語句，直到這些語句被統一提交或回滾。
2-禁用 自動提交模式
如果禁用自動提交，事務可以跨越多條語句。 在這種情況下，事務可以用COMMIT和ROLLBACK語句來顯式地提交或回滾。
三、MySql中的事務管理
（一）MySQL中事務采用自動提交模式
默認情況下，mysql的事務管理采用的是自動提交模式：DML語句的只要執行一條DML，就開啟了事務，并提交這次事務；于是執行結果會立馬同步到到數據表中。
0.查詢事務管理狀態
show variables like 'autocommit'; 查詢結果 —— ON值，代表自動提交。
查詢結果 —— OFF值，代表 不是自動提交。 需要手動執行 commit;
1.關閉自動提交事務
（1）使用命令
在自動提交模式開啟的情況下，關閉事務的自動提交，手動開啟事務。step1： start transaction; // 該SQL命令含義：關閉了事務的自動提交機制，手動開啟事務管理。step2： 執行若干條DML語句。step3： commit; // 進行事務的提交start transaction命令的作用： 在mysql開啟了“自動提交”模式的狀態下，關閉了事務的自動提交機制，對接下來要執行的DML語句進行手動開啟事務管理。 手動開啟事務管理之后，從此mysql不再將DML語句執行出來的結果立即寫到表中，而是會記錄到事務的日志中。只有開發者手動地進行commit提交成功之后，mysql才會將DML執行結果同步到數據庫的表中。
（2）修改變量值
MySql中事務的自動提交模式。該方式只對當前會話有效 （將off值改為on，則為"開啟"）
set autocommit=off;
或
set autocommit=0;
或
set session autocommit = off關閉后自動提交事務之后,則需要commit來執行每一條語句，相當于手動開啟了事務管理。
不過注意的是set autocommit針對的是會話變量，所以這個設置只在此次會話連接中生效。
2.開啟自動提交事務
set autocommit=on;
或
set autocommit=1;(二）事務間的隔離性
1.引發的相關問題
隔離性是事務管理的四大特性之一，事務之間存在隔離級別。事務的隔離級別決定了事務之間可見的級別。
理論上隔離級別包括4個： 低 ——高因事務之間的隔離性引發的相關問題當多個客戶端并發地訪問同一個表時，可能出現下面的一致性問題：
（1）臟讀取
一個事務開始讀取了某行數據，但是另外一個事務已經更新了此數據但沒有能夠及時提交，這就出現了臟讀取（Dirty Read）。
（2）不可重復讀
在同一個事務中，同一個讀操作對同一個數據的前后兩次讀取產生了不同的結果，這就是不可重復讀（Non-repeatable Read）。
（3）幻像讀
幻像讀（Phantom Read）是指在同一個事務中以前沒有的行，由于其他事務的提交而出現的新行數據。
2.事務的隔離級別
InnoDB 存儲引擎支持這四種事務的隔離級別。用以控制事務所做的修改，并將修改通告至其它并發的事務： 1-read uncommitted 讀未提交 2- read committed 讀已提交 3- repeatable read 可重復讀 4- serializable 串行化（序列化）
（1）read uncommitted
對方事務A還沒有提交，我們當前事務B可以讀取到對方未提交的數據。 這里讀到的數據，叫“臟數據”或 “臟讀 Dirty Read” 讀未提交存在臟讀（Dirty Read）現象：表示讀到了臟的數據。 1） 事務A和和事務B，事務A未提交的數據，事務B可以讀取。（允許一個事務可以看到其他事務未提交的修改。） 2） 這里讀取到的數據可以叫做“臟數據”或“臟讀 Dirty Read” 3） 讀未提交隔離級別最低，這種級別一般叧在理論上存在，數據庫默認隔離級別一般都高于該隔離級別；
（2）read committed
1） 事務A和事務B，事務A提交的數據，事務B才可讀取到；（允許一個事務只能看到其他事務已經提交的修改，未提交的修改是不可見的。） 2） 該隔離級別高于“讀未提交”級別,解決了: 臟讀現象。 3） 換句話說：對方事務提交之后的數據，當前事務才可讀取到。 4） 該隔離級別可以避免臟數據； 5） 該隔離級別能夠導致“不可重復讀取” 6） Oracle數據庫管理系統默認隔離級別為“讀已提交” （Oracle數據庫支持 READ COMMITTED 和 SERIALIZABLE這兩種事務隔離級別。)
（3）repeatable read
1） 事務A和事務B，事務A提交之后的數據，事務B還是讀取不到。事務B只能讀取到，事務B開啟事務時刻表中的數據。2） 事務B是可重復讀到數據的。（確保如果在一個事務中執行兩次相同的SELECT語句，都能得到相同的結果，不管其他事務是否提交這些修改。 （銀行總賬））3） 這種隔離級別高于“讀已提交”。4） 換句話說，對方提交之后的數據，還是讀取不到。5） 這種隔離級別可以避免“臟讀和不可重復讀”，達到“重復讀取”；6） MySQL數據庫管理系統默認隔離級別為：可重復讀7） 這種隔離級別解決了：不可重復讀問題，達到了“重復讀取”。 該隔離級別存在的問題是：讀取到的數據是幻象。
(4）serializable
序列化讀/串行化讀1 ） 事務A和事務B，事務A在操作數據庫表中數據的時候，事務B叧能排隊等待；（將一個事務與其他事務完 全地隔離。 ） 2） 這種事務隔離級別一般很少使用，吞吐量太低，用戶體驗不好；效率低。需要事務排隊。 3） 事務A和事務B不再并發；避免了“幻想讀”，每一次讀取都是數據庫表中真實的記錄。
3.事務隔離級別的作用范圍
會話級（session）：只對當前會話有效 全局級（global） ： 對所有會話有效
（1.1）查當前會話隔離級別
select @@tx_isolation;
或
select @@session.tx_isolation;（1.2）查看全局隔離級別
select @@global.tx_isolation;（2.1）設置會話隔離級別
set transaction isolation level 隔離級別類型 ;
或
set session transaction isolation level 隔離級別類型 ;（2.2）設置全局隔離級別
set global transaction isolation level 隔離級別類型;4-設置服務器缺省隔離級別
（1）靜態設置：修改配置
關閉服務器，修改my.ini配置文件在 my.ini 文件中的[mysqld]下面添加：
transaction-isolation = 隔離級別類型（2）動態設置：使用命令
在運行的服務器中通過命令方式，動態設置
set [global/session] transaction isolation level 隔離級別類型;四、JDBC中的事務
1-JDBC中的事務默認采用自動提交機制即 ，只要執行任意一條DML語句，JDBC則會自動提交一次事務。 但是在實際的業務當中，通常都是使用N條DML語句共同聯合才能完成的。必須保證他們這些DML語句在同一個事物中同時成功或者同時失敗。典型的案例：銀行轉賬業務
2-代碼演示 “銀行轉賬”業務分析：采用JDBC中默認的自動提交事務機制，會對該業務實現過程中產生的影響。以及給出解決方案。代碼編號：**《Jdbc_Transaction/演示銀行轉賬業務》**3-事務+【行級鎖】的使用1）悲觀鎖/行級鎖 事務必須排隊執行。被選中鎖住的數據不允許被并發修改。 使用方法：select語句后面添加for update即可。如：使用場景： 在實際開發中，在查詢某張表數據時，為了保障數據的真實性，可以使用【行級鎖】（使用方法：在select語句之后添加for update）將需要的這些數據進行鎖住。于是，別的線程開啟的事務將無法對這些數據進行修改。 select ename,job,sal from emp where job = 'manager' for update;這行語句的意思：工作崗位是manager的這些員工數據被鎖定。（行級鎖） 當前事務未結束時，這些數據被鎖住了。其他的事務無法對這些被鎖住的數據進行修改操作。2）樂觀鎖 支持并發，事務也無需排隊。但是會多一個版本號的概念。 多線程并發時，也可以對某條數據進行修改。執行原理：
假設：開啟事務1時，讀取到數據的版本號是1.1。同時開啟事務2，讀取到數據的版本號也是1.1。 事務1先對數據進行了修改，修改之后發現版本號依舊是1.1，和它最初讀取到的版本號一致（說明沒有其他的事務對數據進行了修改）。于是提交事務修改數據。版本號將會變更為1.2。 事務2再進行修改數據，修改之后準備提交時，發現數據的版本號是1.2。和它最初讀取到的版本號不一致（說明有其他的事務對數據進行了修改）。于是會執行回滾操作。
| ename | job | sal | version || ----- | ------- | ---- | ------- || james | manager | 8000 | 1.1 |
3）代碼演示
結合Debug工具查看效果
涉及到兩個程序1-演示程序開啟一個事務.java2-該程序演示修改被鎖定的記錄.java
《Jdbc_Transaction/事務+行級鎖的使用》
五、MyBatis中的事務
九.其他鎖機制在事務操作一個表時，如果使用索引來取值，那么會鎖定到對應行；如果沒有使用索引來取值，那么會鎖定整個表。鎖定之后其他連接無法操作指定行或表。回滾點
作用：回滾點可以指定rollback回退的位置。
> 比如:現在打了100條命令，發現第81打錯了，如果回滾到打了81命令之前一點而不是回滾到開啟事務之前就可以節省下很多時間。創建回滾點： savepoint 回滾點名;
回滾到回滾點： rollback to 回滾點名;
注意事項：回滾點在事務管理關閉(rollback或commit之后)之后失效，**不能在事務之外使用回滾點。
單機事務
分布式事務 即數據庫不是一個。是數據庫集群。分布方式的。一個數據庫不夠北京的數據庫 轉到 南京的數據庫。保證這兩數據庫的事務都成功，才能成功。
來自為知筆記(Wiz)
總結
以上是生活随笔為你收集整理的事务(Transaction)管理机制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： php 去掉数组中的空值_PHP删除数组
- 下一篇： thinkphp 助手函数url不生成h