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

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

所屬專欄：?MYSQL

目錄

事務(wù)的概念?

事務(wù)的ACID特性

使用事務(wù)

查看支持事務(wù)的存儲引擎?

事務(wù)的語法?

保存點?

自動/手動提交事務(wù)

事務(wù)的隔離性和隔離級別

---

事務(wù)的概念?

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

事務(wù)的ACID特性

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

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

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

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

使用事務(wù)

查看支持事務(wù)的存儲引擎?

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

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

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

事務(wù)的語法?

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

注意：無論是commit 還是 rollback 都會把事務(wù)關(guān)閉。

下面就來進行實操：

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

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

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

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

保存點?

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

語法：

savepoint savepoint_name; 

示例：

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

自動/手動提交事務(wù)

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

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

show variables like 'autocommit';

如果value對應的是off，就是關(guān)閉的意思。

可以通過以下語句設(shè)置事務(wù)為自動或手動提交：

-- 設(shè)置事務(wù)為自動提交
set autocommit = 1; -- 方式一
set autocommit = on; -- 方式二-- 設(shè)置事務(wù)為手動提交
set autocommit = 0; -- 方式一
set autocommit = off; -- 方式二

其實就是把自動提交開啟或者關(guān)閉即可。

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

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

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

3、已提交的事務(wù)是不能夠回滾的。

事務(wù)的隔離性和隔離級別

隔離性的概念：?

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

隔離級別分類：

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

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

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

READ UNCOMMITED —— 在讀取數(shù)據(jù)時，可以讀取到用戶正在編輯的數(shù)據(jù)。這些數(shù)據(jù)處于事務(wù)中，但是還未提交。雖然性能高，但會造成一種現(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)不可重復讀的基礎(chǔ)上，進行了改進。既然這些數(shù)據(jù)在被讀取時，可能刷新一下就變樣了，那直接把這些數(shù)據(jù)加上枷鎖，那么用戶就不能進行修改了。但還會出現(xiàn)另外一個問題，此時用戶往這個表中插入了數(shù)據(jù)，即結(jié)果集的條數(shù)發(fā)生了變化。這種現(xiàn)象叫做‘幻讀’。

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

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