MySQL事務(wù)處理問題的正確解決
如果你研究到庫存系統(tǒng)的開發(fā)問題時，你就會從這里出發(fā)考慮了一些有關(guān)庫存信息中需要的操作和，一般的情況下會遇到的MySQL事務(wù)處理問題。特別是關(guān)于數(shù)據(jù)表鎖定問題，一旦出現(xiàn)并發(fā)現(xiàn)象的時候，我們?nèi)绾伪ＷC數(shù)據(jù)的完整性，值得我們考慮。
事務(wù)操作，要保證的三個原則性：
原子性（Atomicity）：事務(wù)是一個原子操作單元，其對數(shù)據(jù)的修改，要么全部執(zhí)行，要么全都不執(zhí)行；
一致性（Consistent）：在事務(wù)開始和完成時，數(shù)據(jù)都必須保持一致狀態(tài)；
隔離性（Isolation）：數(shù)據(jù)庫系統(tǒng)提供一定的隔離機(jī)制，保證事務(wù)在不受外部并發(fā)操作影響的“獨(dú)立”環(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ù)
此刻沒有提交進(jìn)行commit
在此狀態(tài)下B開始了自己的MySQL事務(wù)處理：
顯然，在A沒有進(jìn)行Commit行為的時候，B的事務(wù)中的動作無法完成，一直處于事務(wù)等待階段，前提是在沒有超出時限，B的動作無法提交。
此刻，如果A進(jìn)行Commit:
此刻 B的動作中，由等待的
轉(zhuǎn)變到
說明A完成事務(wù)開始解鎖，B事務(wù)可以進(jìn)行，但是此刻B事務(wù)沒有提交（Commit）
注意：在這里我們進(jìn)行兩個操作，就是兩個對象進(jìn)行查詢
A的查詢：
依然存在ID為1的這項，原因是B的結(jié)果沒提交，但A依舊可以讀該項數(shù)據(jù)，但是數(shù)據(jù)為刪除前的數(shù)據(jù)。
但是，對照B的查詢：
可以知道，B對象結(jié)果已經(jīng)在處理了，只是沒有提交解鎖。
分析可以知道，A讀的是B沒有提交前的結(jié)果集合，但B讀的是自己操作的結(jié)果集，當(dāng)B完成提交的時候
此刻，A的結(jié)果集合
發(fā)現(xiàn)現(xiàn)在狀態(tài)下和B的集合一樣，A=B，這也是在理論值的范圍內(nèi)的。
由此，可以發(fā)現(xiàn)其實(shí)MySQL鎖的簡單性，當(dāng)然，也說明當(dāng)數(shù)據(jù)庫進(jìn)行鎖操作時候，只能是寫操作控制，對于讀數(shù)據(jù)，往往只能訪問到修改前的數(shù)據(jù)，這部分?jǐn)?shù)據(jù)常常被稱為”dirty”或臟數(shù)據(jù)。在現(xiàn)實(shí)中，我們常常是有這樣的需求，當(dāng)A進(jìn)行寫操作時候，期望B不要讀數(shù)據(jù)，是對讀行為的控制。
這樣保證并發(fā)的時候不要出現(xiàn)B查的時候有，但是這個過程正好是A進(jìn)行寫操作的過程，雖然加鎖防止并發(fā)寫，但是卻把對于B來說他在此過程中所看到的數(shù)據(jù)將被修改，即等A完成寫操作的時候,B讀的數(shù)據(jù)將被丟棄，這樣說來B讀到的數(shù)據(jù)應(yīng)該是臟數(shù)據(jù)，或是無效數(shù)據(jù)，除非A的動作因為某些原因?qū)е率聞?wù)回滾，操作失敗，這樣現(xiàn)實(shí)數(shù)據(jù)結(jié)果和B看到的一致的時候，才斷定B看到的是有效數(shù)據(jù)，而不是臟數(shù)據(jù)或是無效數(shù)據(jù)。
【編輯推薦】
