以下的文章主要向大家描述的是 MySQL 數(shù)據(jù)庫(kù)和相關(guān)事務(wù),在實(shí)際操作中有很多人都認(rèn)為MySQL數(shù)據(jù)庫(kù)對(duì)事務(wù)處理是不支持的,其實(shí),只要MySQL數(shù)據(jù)庫(kù)版本支持BDB或是InnoDB表類型,那么你的MySQL就具有事務(wù)處理的能力。
這里面,又以InnoDB表類型用的最多,雖然后來(lái)發(fā)生了諸如Oracle收購(gòu)InnoDB等令MySQL不爽的事情,但那些商業(yè)上的斗爭(zhēng)與技術(shù)無(wú)關(guān),下面以InnoDB表類型為例簡(jiǎn)單說一下MySQL中的事務(wù)。
先來(lái)明確一下事務(wù)涉及的相關(guān)知識(shí):
事務(wù)都應(yīng)該具備ACID特征。所謂ACID是Atomic(原子性),Consistent(一致性),Isolated(隔離性),Durable(持續(xù)性)四個(gè)詞的首字母所寫,下面以“銀行轉(zhuǎn)帳”為例來(lái)分別說明一下它們的含義:
原子性:組成事務(wù)處理的語(yǔ)句形成了一個(gè)邏輯單元,不能只執(zhí)行其中的一部分。換句話說,事務(wù)是不可分割的最小單元。比如:銀行轉(zhuǎn)帳過程中,必須同時(shí)從一個(gè)帳戶減去轉(zhuǎn)帳金額,并加到另一個(gè)帳戶中,只改變一個(gè)帳戶是不合理的。
一致性:在事務(wù)處理執(zhí)行前后,MySQL數(shù)據(jù)庫(kù)是一致的。也就是說,事務(wù)應(yīng)該正確的轉(zhuǎn)換系統(tǒng)狀態(tài)。比如:銀行轉(zhuǎn)帳過程中,要么轉(zhuǎn)帳金額從一個(gè)帳戶轉(zhuǎn)入另一個(gè)帳戶,要么兩個(gè)帳戶都不變,沒有其他的情況。
隔離性:一個(gè)事務(wù)處理對(duì)另一個(gè)事務(wù)處理沒有影響。就是說任何事務(wù)都不可能看到一個(gè)處在不完整狀態(tài)下的事務(wù)。比如說,銀行轉(zhuǎn)帳過程中,在轉(zhuǎn)帳事務(wù)沒有提交之前,另一個(gè)轉(zhuǎn)帳事務(wù)只能處于等待狀態(tài)。
持續(xù)性:事務(wù)處理的效果能夠被永久保存下來(lái)。反過來(lái)說,事務(wù)應(yīng)當(dāng)能夠承受所有的失敗,包括服務(wù)器、進(jìn)程、通信以及媒體失敗等等。比如:銀行轉(zhuǎn)帳過程中,轉(zhuǎn)帳后帳戶的狀態(tài)要能被保存下來(lái)。
再來(lái)看看哪些問題會(huì)用到事務(wù)處理:
?
這里不說“銀行轉(zhuǎn)帳”的例子了,說一個(gè)大家實(shí)際更容易遇到的“網(wǎng)上購(gòu)書”的例子。先假設(shè)一下問題的背景:網(wǎng)上購(gòu)書,某書(MySQL數(shù)據(jù)庫(kù)編號(hào)為123)只剩最后一本,而這個(gè)時(shí)候,兩個(gè)用戶對(duì)這本書幾乎同時(shí)發(fā)出了購(gòu)買請(qǐng)求,讓我們看看整個(gè)過程:
在具體分析之前,先來(lái)看看數(shù)據(jù)表的定義:
?
- create?table?book ?
- ( ?
- book_id?unsigned?int(10)?not?null?auto_increment, ?
- book_name?varchar(100)?not?null, ?
- book_price?float(5,?2)?not?null,?#我假設(shè)每本書的價(jià)格不會(huì)超過999.99元 ?
- book_number?int(10)?not?null, ?
- primary?key?(book_id) ?
- ) ?
- type?=?innodb;?#engine?=?innodb也行?
對(duì)于用戶甲來(lái)說,他的動(dòng)作稍微比乙快一點(diǎn)點(diǎn),其購(gòu)買過程所觸發(fā)的動(dòng)作大致是這樣的:
1. SELECT book_number FROM book WHERE book_id = 123;
book_number大于零,確認(rèn)購(gòu)買行為并更新book_number
2. UPDATE book SET book_number = book_number - 1 WHERE book_id = 123;
購(gòu)書成功
而對(duì)于用戶乙來(lái)說,他的動(dòng)作稍微比甲慢一點(diǎn)點(diǎn),其購(gòu)買過程所觸發(fā)的動(dòng)作和甲相同:
1. SELECT book_number FROM book WHERE book_id = 123;
這個(gè)時(shí)候,甲剛剛進(jìn)行完第一步的操作,還沒來(lái)得及做第二步操作,所以book_number一定大于零
2. UPDATE book SET book_number = book_number - 1 WHERE book_id = 123;
購(gòu)書成功
表面上看甲乙的操作都成功了,他們都買到了書,但是庫(kù)存只有一本,他們?cè)趺纯赡芏汲晒δ兀吭倏纯磾?shù)據(jù)表里book_number的內(nèi)容,已經(jīng)變成“-1”了,這當(dāng)然是不能允許的(實(shí)際上,聲明這樣的列類型應(yīng)該加上unsigned的屬性,以保證其不能為負(fù),這里是為了說明問題所以沒有這樣設(shè)置)
好了,問題陳述清楚了,再來(lái)看看怎么利用事務(wù)來(lái)解決這個(gè)問題,打開MySQL手冊(cè),可以看到想用事務(wù)來(lái)保護(hù)你的SQL正確執(zhí)行其實(shí)很簡(jiǎn)單,基本就是三個(gè)語(yǔ)句:開始,提交,回滾。
開始:START TRANSACTION或BEGIN語(yǔ)句可以開始一項(xiàng)新的事務(wù)
提交:COMMIT可以提交當(dāng)前事務(wù),是變更成為永久變更
回滾:ROLLBACK可以回滾當(dāng)前事務(wù),取消其變更
此外,SET AUTOCOMMIT = {0 | 1}可以禁用或啟用默認(rèn)的autocommit模式,用于當(dāng)前連接。
那是不是只要用事務(wù)語(yǔ)句包一下我們的SQL語(yǔ)句就能保證正確了呢?比如下面代碼:
?
- BEGIN; ?
- SELECT?book_number?FROM?book?WHERE?book_id?=?123; ?
- //?... ?
- UPDATE?book?SET?book_numberbook_number?=?book_number?-?1?WHERE?book_id?=?123;??
- COMMIT; ?
?
答案是否定了,這樣依然不能避免問題的發(fā)生,如果想避免這樣的情況,實(shí)際應(yīng)該如下:
?
- BEGIN; ?
- SELECT?book_number?FROM?book?WHERE?book_id?=?123?FOR?UPDATE; ?
- //?... ?
- UPDATE?book?SET?book_numberbook_number?=?book_number?-?1?WHERE?book_id?=?123; ?
- COMMIT; ?
?
由于加入了FOR UPDATE,所以會(huì)在此條記錄上加上一個(gè)行鎖,如果此事務(wù)沒有完全結(jié)束,那么其他的事務(wù)在使用SELECT ... FOR UPDATE請(qǐng)求的時(shí)候就會(huì)處于等待狀態(tài),直到上一個(gè)事務(wù)結(jié)束,它才能繼續(xù),從而避免了問題的發(fā)生,需要注意的是,如果你其他的事務(wù)使用的是不帶FOR UPDATE的SELECT語(yǔ)句,將得不到這種保護(hù)。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號(hào)聯(lián)系: 360901061
您的支持是博主寫作最大的動(dòng)力,如果您喜歡我的文章,感覺我的文章對(duì)您有幫助,請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點(diǎn)擊下面給點(diǎn)支持吧,站長(zhǎng)非常感激您!手機(jī)微信長(zhǎng)按不能支付解決辦法:請(qǐng)將微信支付二維碼保存到相冊(cè),切換到微信,然后點(diǎn)擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
