MySQL事務的基礎學習以及心得分享
事務是邏輯上的一組操作,組成這組操作的各個單元,要不全都成功要不全都失敗,這個特性就是事務,下面就是關于MySQL事務學習中的心得分享:
事務的特性
1.原子性(Atomicity):原子性是指事務是一個不可分割的工作單位,事務中的操作要么都發(fā)生,要么都不發(fā)生。
2.一致性(Consistency):在一個事務中,事務前后數(shù)據(jù)的完整性必須保持一致,可以想象銀行轉賬、火車購票。
3.隔離性(Isolation):多個事務,事務的隔離性是指多個用戶并發(fā)訪問數(shù)據(jù)庫時, 一個用戶的事務不能被其它用戶的事務所干擾,多個并發(fā)事務之間數(shù)據(jù)要相互隔離。
4.持久性(Durability):持久性是指一個事務一旦被提交,它對數(shù)據(jù)庫中數(shù)據(jù)的改變就是永久性的,接下來即使數(shù)據(jù)庫發(fā)生故障也不應該對其有任何影響。
寫這些概念呢,是有點繞!繞就繞吧!反正也不是我規(guī)定的,這是官方的,解釋是我編的?。?!
事務的并發(fā)訪問問題
如果我們在不考慮隔離性問題時,事務是存在三種并發(fā)訪問問題的。
1.臟讀:在一個事務中,當讀取數(shù)據(jù)時,讀到了另一個事務未提交的數(shù)據(jù)。
比如A賬戶給B賬戶轉了1塊錢,但是A沒有提交事務,被B賬戶通過臟讀看到了,這時,B就會以為A已經把錢轉過來了,但是這時,A賬戶回滾事務。其實錢就沒給B轉過去,但是B自己本身以為A已經轉過去了,,,有點繞,估計是我描述到繞!
看代碼:
update account set money=money+1 where name='B'; --此時A去通知B update account set money=money -1 where name='A';
2.不可重復讀:在一個事務中,兩次讀取的數(shù)據(jù)內容不一致,這是因為在查詢時,有時間間隔,數(shù)據(jù)被另一個事務已經修改提交了,那就會出現(xiàn)問題。
3.幻讀/虛讀:在一個事務中,兩次讀取的數(shù)據(jù)量不一致。
事務的隔離級別
上面介紹了3種事務并發(fā)問題!現(xiàn)在介紹一下數(shù)據(jù)庫提供的解決方案!
1.read uncommitted : 讀取尚未提交的數(shù)據(jù) :這個最低級,但是效率肯定最高,但是哪一個問題都不能解決。
2.read committed:讀取已經提交的數(shù)據(jù) :可以解決臟讀 。
3.repeatable read:重讀讀?。嚎梢越鉀Q臟讀 和 不可重復讀 。
4.serializable:串行化:可以解決臟讀不可重復讀和虛讀,效率最差,相當于鎖表,開發(fā)中一般不用。
上面的“2”是oracle數(shù)據(jù)庫默認設置,“3”是mysql數(shù)據(jù)庫默認的設置。
下面呢我就重點解釋一下mysql數(shù)據(jù)庫在上面各種事務隔離級別上的演示:
首先介紹兩個語法:
1.查看mysql數(shù)據(jù)庫默認的隔離級別:select @@tx_isolation
如圖:
2.設置mysql的隔離級別:set session transaction isolation level 事務的隔離級別
如圖:
事務的隔離級別演示
注意:如果要自己模擬要開啟兩個mysql客戶端,也就是模擬兩個用戶!
1.read uncommitted
如圖:
我通過語法將數(shù)據(jù)庫的事務隔離級別改為了read uncommitted。
首先我有一張account表。
如圖:窗口一
窗口二
數(shù)據(jù)庫表原始數(shù)據(jù)money都是5000,當我啟動事務后,在zhangsan賬戶增加了1000和在李四賬戶減去了1000,但是我的事務還未提交,但是我再次查詢數(shù)據(jù)庫表時,數(shù)據(jù)已經發(fā)生變化,這就是臟讀和不可重復讀!
幻讀/虛讀我就不掩飾了,同樣存在!
2.read committed
如圖:
我將數(shù)據(jù)庫事務隔離性改為了read committted。
還是上面那張表:
如圖:窗口一
窗口二
數(shù)據(jù)庫表zhangsan賬戶的money和lisi賬戶的money都發(fā)生了變化,我未提交事務,在另一個窗口事務開啟下查詢時,沒有出現(xiàn)臟讀,但是當我提交事務時,在另一個窗口的事務下再次查詢,出現(xiàn)了不可重復讀的情況,這樣可以避免臟讀,但是查詢時已經出現(xiàn)不可重復讀和幻讀/虛讀!
3.repeatable read
如圖:
我將數(shù)據(jù)庫事務隔離性改為了read committted。
還是上面那張表:
如圖:窗口一
窗口二
我在兩個窗口都開啟了事務,當窗口一進行數(shù)據(jù)操作后,并進行事務提交,在窗口二的事務開啟情況下,我去查詢,沒有查詢到剛才窗口一的數(shù)據(jù)操作記錄,這樣就避免了臟讀和不可重復讀。
有人說也避免了虛讀/幻讀,其實沒有。
看圖:
我在操作lisi賬戶時,數(shù)據(jù)只是發(fā)生修改的變化,但是當我修改wangwu這個賬戶時,再去查詢出現(xiàn)了wangwu,賬戶的數(shù)據(jù),但是其實在我未操作前,wangwu賬戶的數(shù)據(jù)是查詢不出的。這就是幻讀/虛讀!
如果不理解幻讀/虛讀這塊,可以查一下InnoDB。
4.serializable
我就不演示了,開發(fā)不建議用,效率又慢,但是所有的問題都能避免!!
總結一下
事務隔離級別的性能:
read uncommitted>read committed>repeatable read>serialazable
事務隔離級別的安全性:
read uncommitted<read committed<repeatable read<serialazable
mysql 事務控制:
開啟事務:start transaction;
提交:commit;
回滾:rollback;
版權聲明:本站文章來源標注為YINGSOO的內容版權均為本站所有,歡迎引用、轉載,請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網站,禁止在非www.sddonglingsh.com所屬的服務器上建立鏡像,否則將依法追究法律責任。本站部分內容來源于網友推薦、互聯(lián)網收集整理而來,僅供學習參考,不代表本站立場,如有內容涉嫌侵權,請聯(lián)系alex-e#qq.com處理。