重溫事務(wù)的概念

為什么用事務(wù)、事務(wù)是什么

我們規(guī)定了，做一件事情，只有成功和失敗!
用個(gè)很經(jīng)典的例子舉例：
銀行轉(zhuǎn)賬，A向B轉(zhuǎn)賬十萬，能不能發(fā)生一遍付錢一邊沒收錢的情況？
現(xiàn)實(shí)中一定是A和B同時(shí)成功或者失敗，不能出現(xiàn)一邊成功另一邊失敗的情景，這就是事務(wù)的簡單例子。

那么由這個(gè)例子我們想想事務(wù)其實(shí)是為了保證什么？

假如：

• 張三問羅老師借錢，借了錢沒寫借據(jù)。
• 這是做了事情，但是沒有依據(jù)，就算做成功了，也沒辦法證明。突出借據(jù)的重要性（持久性） redolog
• 張三問羅老師借錢，羅老師同意了，可是張三不想借了。

這是事情做成功了，關(guān)鍵點(diǎn)在于，我可不可以反悔。（張三去決定）突出回滾的重要性（原子性）undo log

所以**事務(wù)其實(shí)就是想要做的事情是一個(gè)整體！**事務(wù)的存在目的就是為了事情能夠正確成功的執(zhí)行。

如果以數(shù)據(jù)庫的角度去看：

在關(guān)系型數(shù)據(jù)庫中，事務(wù)其實(shí)就是【一組原子性的SQL】或者說一個(gè)獨(dú)立不可分割的工作單元，如果數(shù)據(jù)庫引擎能成功的對數(shù)據(jù)庫引用該組查詢的全部語句，那么就執(zhí)行該組查詢，如果其中有任何一條語句因?yàn)楸罎⒒蛘咂渌驘o法執(zhí)行，那么所有的語句都不會(huì)執(zhí)行，也就是說，事務(wù)內(nèi)的語句，要么全部執(zhí)行成功，要么全部執(zhí)行失敗。

那么剛才那個(gè)轉(zhuǎn)賬的例子，讓我們?nèi)懸粋€(gè)事務(wù)，應(yīng)該怎么寫？

查詢A賬戶的余額是否大于10W塊錢從A賬戶余額中減去10W塊錢在B賬戶余額中增加10W塊錢

怎么用事務(wù)

還記得怎么寫事務(wù)的sql語句嗎？

--開啟一個(gè)事務(wù)
BEGIN;--等價(jià)于 START TRANSACTION;
--執(zhí)行我們需要的SQL
--提交事務(wù)
COMMIT;
--回滾事務(wù)
ROLLBACK;

我們來模擬一下A的兩個(gè)賬戶（CMBC銀行、ICBC銀行）之間轉(zhuǎn)賬的事務(wù)

# 開啟轉(zhuǎn)賬事務(wù)
BEGIN;
SELECT BALANCE FROM BANK_CMBC WHERE USER_NAME = 'A的CMBC銀行賬戶';
# 這里需要判斷余額 是否大于等于 10W
UPDATE BANK_CMBC SET BALANCE = BALANCE - 100000 WHERE USER'A的CMBC銀行賬戶';
UPDATE BANK_ICBC SET BALANCE = BALANCE + 100000 WHERE USER'A的ICBC銀行賬戶';
# 這里當(dāng)然還需要記錄 記錄表 日志表 轉(zhuǎn)賬記錄表 等
SELECT * FROM BANK_CMBC;
SELECT * FROM BANK_ICBC;
--提交
COMMIT;
--或者回滾
ROLLBACK;
# BANK_CMBC 里的余額會(huì)減去10W 然后 BANK_ICBC賬戶增加10W，
# 這個(gè)就是我們事務(wù)的具體使用場景了，要么全部成功要么全部失??！

我能不能只提交一部分事務(wù)，一部分事務(wù)不提交呢？
也可以，使用SAVEPOINT，但是呢，要記得提交。

BEGIN;
SELECT BALANCE FROM BANK_CMBC WHERE USER_NAME = 'A的CMBC銀行賬戶';
# 這里需要判斷余額 是否大于等于 10W
UPDATE BANK_CMBC SET BALANCE = BALANCE - 100000 WHERE USER_NAME ='A的CMBC銀行賬戶';
SAVEPOINT A;--設(shè)置回滾點(diǎn)
UPDATE BANK_ICBC SET BALANCE = BALANCE + 100000 WHERE USER_NAME ='A的ICBC銀行賬戶';
# 這里當(dāng)然還需要記錄 記錄表 日志表 轉(zhuǎn)賬記錄表 等
# 回滾到保存點(diǎn)
ROLLBACK TO A;
SELECT * FROM BANK_CMBC;
SELECT * FROM BANK_ICBC;
COMMIT;

# 這個(gè)時(shí)候我們的記錄是多少？
# 我們看一下 在SAVEPOINT 之前的語句都能正確提交，SAVEPOINT之后的語句因?yàn)槲覀兪謩?dòng)回滾了他們是沒有被更改成的，這
# 就是SAVEPOINT的作用，他能夠在一個(gè)事務(wù)里開啟一個(gè)嵌套事務(wù)。主事務(wù)和嵌套事務(wù)屬于同一個(gè)事務(wù)，嵌套事務(wù)出錯(cuò)回滾不會(huì)影響主事務(wù)，主事務(wù)回滾會(huì)將嵌套事務(wù)一起回滾。主事務(wù)提交嵌套事務(wù)也會(huì)跟著提交。

問一個(gè)面試官可能會(huì)問到的問題，我們知道多條SQL語句開啟的時(shí)候，能保證全部成功、或者全部失敗。那么單條SQL語句有沒有事務(wù)呢？
其實(shí)每個(gè)語句都是原子性的，他們被隱式的加入了 BEGIN; START TRANSACTION 開啟事務(wù)，并COMMIT;
就好像：

BEGIN;
UPDATE BANK CMBC SET BALANCE = BALANCE + 100000 WHERE USER_NAME = 'A的CMBC銀行賬戶';
COMMIT;
# 如果在語句執(zhí)行期間發(fā)生錯(cuò)誤，則會(huì)回滾該語句。
# 但是如果每個(gè)語句都這么寫，挺麻煩的。所以在事務(wù)里有一個(gè)概念叫做自動(dòng)提交設(shè)置！
# 我們每個(gè)單語句都會(huì)自動(dòng)提交的，可以自行關(guān)閉自動(dòng)提交！默認(rèn)是開啟的，這個(gè)也區(qū)別于全局global和會(huì)話session

show session VARIABLES like 'autocommit'; --查詢自動(dòng)開啟提交
show global variables like 'autocommit'; --查詢自動(dòng)開啟提交
set SESSION autocommit=0; --關(guān)閉自動(dòng)提交

總結(jié)：數(shù)據(jù)庫的事務(wù)都是為了解決這種業(yè)務(wù)場景出現(xiàn)的一門技術(shù)，為了保證多個(gè)SQL語句，要么全部執(zhí)行成功，要么全部執(zhí)行失敗。

事務(wù)的四大特性是什么?

原子性

一個(gè)事務(wù)必須被視為一個(gè)不可分割的最小單元，整個(gè)事務(wù)中的操作要么全部提交成功，要么全部失敗回滾，對于一個(gè)事務(wù)來說，不可能只執(zhí)行其中的一部分操作。

一致性

數(shù)據(jù)庫總是由一個(gè)一致性狀態(tài)轉(zhuǎn)換到另外一個(gè)一致性狀態(tài)。在前面的例子中，一致性確保了，即使在執(zhí)行第三條第四條預(yù)計(jì)之間系統(tǒng)崩潰了，CMBC賬戶中也不會(huì)損失10W，要不然A要哭死，如果是系統(tǒng)崩潰最終事務(wù)沒有提交，所有事務(wù)中所作的修改也不會(huì)保存到數(shù)據(jù)庫中。

持久性

俗話說就是保證及時(shí)落盤；
持久性是為了保證斷點(diǎn)等異常的情況，還能保證我們commit的數(shù)據(jù)不丟失！并且不會(huì)回滾！
不會(huì)出現(xiàn)我commit之后，重啟后又被回滾了！

剛才寫了有個(gè)undolog能保證原子性，同樣的，也有個(gè)redolog（重做日志）去保證特殊情況的數(shù)據(jù)丟失！
redolog會(huì)記錄每次事務(wù)的執(zhí)行語句！當(dāng)發(fā)生斷電等比較不可控的因素后，能根據(jù)redolog進(jìn)行數(shù)據(jù)恢復(fù)?。?！

隔離性

一個(gè)事務(wù)所作的修改在最終提交之前，對其他事務(wù)是不可見的。在前面的例子中，我們執(zhí)行完第三條語句，第四條語句還沒成功執(zhí)行的時(shí)候，事務(wù)尚未提交。這個(gè)時(shí)候去看我們ACMBC中的賬號(hào)還有10W，如果這個(gè)時(shí)候去取錢是不可以的，要等待事務(wù)提交了才可以。

剛才我們所看到的，是不是都是一個(gè)人或者說是一個(gè)線程的問題？
假如我們有很高的并發(fā)量，如果有多個(gè)事務(wù)同時(shí)操作同一條數(shù)據(jù)，會(huì)導(dǎo)致什么？
事務(wù)因并發(fā)出現(xiàn)的問題有哪些？可以查看另一篇文章
鏈接: 

到此這篇關(guān)于MySQL的事務(wù)特性概念梳理總結(jié)的文章就介紹到這了,更多相關(guān)MySQL事務(wù)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論