如果你研究到庫存系統(tǒng)的開發(fā)問題時，你就會從這里出發(fā)考慮了一些有關(guān)庫存信息中需要的操作和，一般的情況下會遇到的MySQL事務(wù)處理問題。特別是關(guān)于數(shù)據(jù)表鎖定問題，一旦出現(xiàn)并發(fā)現(xiàn)象的時候，我們?nèi)绾伪ＷC數(shù)據(jù)的完整性，值得我們考慮。

成都創(chuàng)新互聯(lián)于2013年開始，先為古浪等服務(wù)建站，古浪等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為古浪企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

事務(wù)操作，要保證的三個原則性：

原子性（Atomicity）：事務(wù)是一個原子操作單元，其對數(shù)據(jù)的修改，要么全部執(zhí)行，要么全都不執(zhí)行；

一致性（Consistent）：在事務(wù)開始和完成時，數(shù)據(jù)都必須保持一致狀態(tài)；

隔離性（Isolation）：數(shù)據(jù)庫系統(tǒng)提供一定的隔離機制，保證事務(wù)在不受外部并發(fā)操作影響的“獨立”環(huán)境執(zhí)行；

持久性（Durable）：事務(wù)完成之后，它對于數(shù)據(jù)的修改是***性的，即使出現(xiàn)系統(tǒng)故障也能夠保持。

于是，我們假設(shè)兩個對象A和B

并發(fā)對象A 和B

初始狀態(tài)數(shù)據(jù)表查詢結(jié)果:

事務(wù)開始的順序 A->B

A：開始事務(wù)

此刻沒有提交進行commit

在此狀態(tài)下B開始了自己的MySQL事務(wù)處理：

顯然，在A沒有進行Commit行為的時候，B的事務(wù)中的動作無法完成，一直處于事務(wù)等待階段，前提是在沒有超出時限，B的動作無法提交。

此刻，如果A進行Commit:

此刻 B的動作中，由等待的

轉(zhuǎn)變到

說明A完成事務(wù)開始解鎖，B事務(wù)可以進行，但是此刻B事務(wù)沒有提交（Commit）

注意：在這里我們進行兩個操作，就是兩個對象進行查詢

A的查詢：

依然存在ID為1的這項，原因是B的結(jié)果沒提交，但A依舊可以讀該項數(shù)據(jù)，但是數(shù)據(jù)為刪除前的數(shù)據(jù)。

但是，對照B的查詢：

可以知道，B對象結(jié)果已經(jīng)在處理了，只是沒有提交解鎖。

分析可以知道，A讀的是B沒有提交前的結(jié)果集合，但B讀的是自己操作的結(jié)果集，當B完成提交的時候

此刻，A的結(jié)果集合

發(fā)現(xiàn)現(xiàn)在狀態(tài)下和B的集合一樣，A=B，這也是在理論值的范圍內(nèi)的。

由此，可以發(fā)現(xiàn)其實MySQL鎖的簡單性，當然，也說明當數(shù)據(jù)庫進行鎖操作時候，只能是寫操作控制，對于讀數(shù)據(jù)，往往只能訪問到修改前的數(shù)據(jù)，這部分數(shù)據(jù)常常被稱為”dirty”或臟數(shù)據(jù)。在現(xiàn)實中，我們常常是有這樣的需求，當A進行寫操作時候，期望B不要讀數(shù)據(jù)，是對讀行為的控制。

這樣保證并發(fā)的時候不要出現(xiàn)B查的時候有，但是這個過程正好是A進行寫操作的過程，雖然加鎖防止并發(fā)寫，但是卻把對于B來說他在此過程中所看到的數(shù)據(jù)將被修改，即等A完成寫操作的時候,B讀的數(shù)據(jù)將被丟棄，這樣說來B讀到的數(shù)據(jù)應(yīng)該是臟數(shù)據(jù)，或是無效數(shù)據(jù)，除非A的動作因為某些原因?qū)е率聞?wù)回滾，操作失敗，這樣現(xiàn)實數(shù)據(jù)結(jié)果和B看到的一致的時候，才斷定B看到的是有效數(shù)據(jù)，而不是臟數(shù)據(jù)或是無效數(shù)據(jù)。

分享文章：MySQL事務(wù)處理問題的正確解決
URL標題：http://uogjgqi.cn/article/dhecdoh.html