找往期文章包括但不限于本期文章中不懂的知識點：

個人主頁：我要學編程(?_?)-CSDN博客

所屬專欄：?MYSQL

目錄

事務的概念?

事務的ACID特性

使用事務

查看支持事務的存儲引擎?

事務的語法?

保存點?

自動/手動提交事務

事務的隔離性和隔離級別

---

事務的概念?

首先，得了解什么是事務？?事務將一組SQL語句打包成一個整體，在這組SQL語句的執(zhí)行過程中，要么全部成功，要么全部失敗，以保證數(shù)據(jù)的一致性。

事務的ACID特性

事務的ACID特性指的是 Atomicity (原子性)， Consistency (一致性)， Isolation (隔離性)和 Durability (持久性)。?

Atomicity(原子性)：一個事務中的所有操作，要么全部成功，要么全部失敗，不會出現(xiàn)只執(zhí)
行了一半的情況，如果事務在執(zhí)行過程中發(fā)生錯誤，會回滾（Rollback）到事務開始前的狀
態(tài)，就像這個事務從來沒有執(zhí)行過一樣；
Consistency(一致性)：在事務開始之前和事務結束以后，數(shù)據(jù)庫的完整性不會被破壞。這表
示寫入的數(shù)據(jù)必須完全符合所有的預設規(guī)則，包括數(shù)據(jù)的精度、關聯(lián)性以及關于事務執(zhí)行過程中服
務器崩潰后如何恢復。簡單理解就是事務開始前后的數(shù)據(jù)量要一致；
Isolation（隔離性)：數(shù)據(jù)庫允許多個并發(fā)事務同時對數(shù)據(jù)進行讀寫和修改，隔離性可以防止多
個事務并發(fā)執(zhí)行時由于交叉執(zhí)行而導致數(shù)據(jù)的不一致。事務可以指定不同的隔離級別，以權衡在不
同的應用場景下數(shù)據(jù)庫性能和安全;
Durabi禮ity（持久性)：事務處理結束后，對數(shù)據(jù)的修改將永久的寫入存儲介質，即便系統(tǒng)故障
也不會丟失。

正因為事務具備上述四個特性，保證了在使用事務過程中，要么提交，要么回滾，不用去考慮網(wǎng)絡異常，服務器宕機等其他因素，因此事務在數(shù)據(jù)庫的使用是非常頻繁的。

既然事務這么好用，那么我們該怎么去使用事務呢？?

使用事務

查看支持事務的存儲引擎?

在使用事務之前，得查看我們本機的數(shù)據(jù)庫是否支持事務。

在MySQL中支持事務的存儲引擎是InnoDB，可以通過 show engines; 語句查看：

知道了本機中的數(shù)據(jù)庫是支持事務之后，便可以開始進行事務了。

事務的語法?

-- 開始一個新的事務
start transaction;
-- 或者下面這種寫法
begin;-- 提交當前事務，并對SQL語句的執(zhí)行而影響的數(shù)據(jù)進行持久化保存
commit;-- 回滾當前事務，并取消SQL語句的執(zhí)行而影響的數(shù)據(jù)
rollback;

注意：無論是commit 還是 rollback 都會把事務關閉。

下面就來進行實操：

-- 開啟事務
start transaction;-- 插入一條數(shù)據(jù)
insert into student values (NULL, '小紅', 18, 0);-- 在事務中查看student表中的結果集
select * from student;-- 回滾事務
rollback;-- 在回滾之后，再查看student表中的結果集
select * from student; 

從上面的結果，我們就可以看出回滾之后，事務中的SQL語句全部失效。現(xiàn)在我們再來觀察commit 的效果。?

-- 開啟事務
start transaction;-- 插入一條數(shù)據(jù)
insert into student values (NULL, '小紅', 18, 0);-- 在事務中查看student表中的結果集
select * from student;-- 提交事務
commit;-- 在提交之后，再查看student表中的結果集
select * from student; 

從上面的結果，我們可以看出提交事務之后，事務中的SQL語句便生效了。?

保存點?

在事務執(zhí)行的過程中設置保存點，回滾時指定保存點可以把數(shù)據(jù)恢復到保存點的狀態(tài)。當事務中有多個修改數(shù)據(jù)的SQL語句時（包括插入、刪除、更新），便可以設置多個保存點，以保證數(shù)據(jù)的一致性和操作方便。

語法：

savepoint savepoint_name; 

示例：

-- 開啟事務
start transaction;-- 修改多條數(shù)據(jù)savepoint sp1; -- 設置第一個保存點
delete from student where id = 8 or id = 9;
select * from student;savepoint sp2; -- 設置第二個保存點
insert into student values (NULL, '小麗', 19, 0);
select * from student;savepoint sp3; -- 設置第三個保存點
update student set age = 20 where name = '張三';
select * from student;-- 可以通過回滾到某一個保存點來取消修改
rollback to sp3; 
select * from student;-- 如果rollback后面啥也不跟，那就是默認回滾到事務開始之前，并關閉事務
rollback;
select * from student;

自動/手動提交事務

默認情況下，MySQL是自動提交事務的，也就是說我們執(zhí)行的每個修改操作，比如插入、更新和刪除，都會自動開啟一個事務并在語句執(zhí)行完成之后自動提交，發(fā)生異常時自動回滾。即每一條SQL語句對應著一個事務。

查看當前事務是否自動提交可以使用以下語句：

show variables like 'autocommit';

如果value對應的是off，就是關閉的意思。

可以通過以下語句設置事務為自動或手動提交：

-- 設置事務為自動提交
set autocommit = 1; -- 方式一
set autocommit = on; -- 方式二-- 設置事務為手動提交
set autocommit = 0; -- 方式一
set autocommit = off; -- 方式二

其實就是把自動提交開啟或者關閉即可。

使用事務的時候，要注意一下三點：

1、只要使用start transaction 或 begin 開啟事務，必須要通過commit 提交才會持久化，與是否設置set commit 無關。因為我們手動開啟事務之后，必須要自己手動關閉事務。

2、手動提交模式下，不用顯示開啟事務，執(zhí)行修改操作后，提交或回滾事務時直接使用commit
或rollback。因為手動提交下，就是需要我們自己把事務手動提交。

3、已提交的事務是不能夠回滾的。

事務的隔離性和隔離級別

隔離性的概念：?

MySQL服務可以同時被多個客戶端訪問，每個客戶端執(zhí)行的SQL語句是以事務為基本單位，那么不同的客戶端在對同一張表中的同一條數(shù)據(jù)進行修改的時候就可能出現(xiàn)相互影響的情況，為了保證不同的事務之間在執(zhí)行的過程中不受影響，那么事務之間就需要要相互隔離，這種特性就是隔離性。這就類似于我們在食堂里面打飯的場景，同一個窗口，同一份飯菜，肯定有先來后到，不可能出現(xiàn)兩個人同時拿到這份飯菜(假設不存在多個阿姨打飯的情況)。這就隔離開了。

隔離級別分類：

事務具有隔離性，那么如何實現(xiàn)事務之間的隔離？隔離到什么程度？如何保證數(shù)據(jù)安全的同時也
要兼顧性能？這都是要思考的問題。

事務間不同程度的隔離，稱為事務的隔離級別；不同的隔離級別在性能和安全方面做了取舍，有
的隔離級別注重并發(fā)性，有的注重安全性，有的則是并發(fā)和安全適中；在MySQL的InnoDB引擎中事務的隔離級別有四種，分別是：
READ UNCOMMITTED，讀未提交?—— 性能最強，但安全性最差。
READCOMMITTED，讀已提交 —— 性能稍遜于讀未提交，安全性比讀未提交高。
REPEATABLE READ，可重復讀(InnoDB默認) —— 性能比讀已提交差，安全性比讀已提交高。
SERIALIZABLE，串行化? —— 性能最差，但安全性最高。

下面就來解釋上面四種隔離級別：

READ UNCOMMITED —— 在讀取數(shù)據(jù)時，可以讀取到用戶正在編輯的數(shù)據(jù)。這些數(shù)據(jù)處于事務中，但是還未提交。雖然性能高，但會造成一種現(xiàn)象'臟讀'——讀取的數(shù)據(jù)不一定是真實的，可以用戶后面會進行修改，再提交。

READ COMMITED —— 和上面的一對比，我們就知道這個是只能讀取已經(jīng)提交的數(shù)據(jù)。但這還會造成一種現(xiàn)象‘不可重復讀’——可能現(xiàn)在這個時刻讀取的數(shù)據(jù)內(nèi)容是這樣的，但是在另外一個時刻讀取的數(shù)據(jù)內(nèi)容確實另外的。

REPEATABLE READ —— 在出現(xiàn)不可重復讀的基礎上，進行了改進。既然這些數(shù)據(jù)在被讀取時，可能刷新一下就變樣了，那直接把這些數(shù)據(jù)加上枷鎖，那么用戶就不能進行修改了。但還會出現(xiàn)另外一個問題，此時用戶往這個表中插入了數(shù)據(jù)，即結果集的條數(shù)發(fā)生了變化。這種現(xiàn)象叫做‘幻讀’。

SERIALIZABLE —— 這個就是和我們學過的隊列一樣，數(shù)據(jù)是一次一次的讀取。致使其不會出現(xiàn)安全問題，但是效率相比之下就慢很多。

好啦！本期?初始MYSQL數(shù)據(jù)庫（5）—— 事務 的學習之旅就到此結束啦！我們下一期再一起學習吧！