MySQL事務處理問題的正確解決
如果你研究到庫存系統的開發問題時，你就會從這里出發考慮了一些有關庫存信息中需要的操作和，一般的情況下會遇到的MySQL事務處理問題。特別是關于數據表鎖定問題，一旦出現并發現象的時候，我們如何保證數據的完整性，值得我們考慮。
事務操作，要保證的三個原則性：
原子性（Atomicity）：事務是一個原子操作單元，其對數據的修改，要么全部執行，要么全都不執行；
一致性（Consistent）：在事務開始和完成時，數據都必須保持一致狀態；
隔離性（Isolation）：數據庫系統提供一定的隔離機制，保證事務在不受外部并發操作影響的“獨立”環境執行；
持久性（Durable）：事務完成之后，它對于數據的修改是***性的，即使出現系統故障也能夠保持。
于是，我們假設兩個對象A和B
并發對象A 和B
初始狀態數據表查詢結果:
事務開始的順序 A->B
A：開始事務
此刻沒有提交進行commit
在此狀態下B開始了自己的MySQL事務處理：
顯然，在A沒有進行Commit行為的時候，B的事務中的動作無法完成，一直處于事務等待階段，前提是在沒有超出時限，B的動作無法提交。
此刻，如果A進行Commit:
此刻 B的動作中，由等待的
轉變到
說明A完成事務開始解鎖，B事務可以進行，但是此刻B事務沒有提交（Commit）
注意：在這里我們進行兩個操作，就是兩個對象進行查詢
A的查詢：
依然存在ID為1的這項，原因是B的結果沒提交，但A依舊可以讀該項數據，但是數據為刪除前的數據。
但是，對照B的查詢：
可以知道，B對象結果已經在處理了，只是沒有提交解鎖。
分析可以知道，A讀的是B沒有提交前的結果集合，但B讀的是自己操作的結果集，當B完成提交的時候
此刻，A的結果集合
發現現在狀態下和B的集合一樣，A=B，這也是在理論值的范圍內的。
由此，可以發現其實MySQL鎖的簡單性，當然，也說明當數據庫進行鎖操作時候，只能是寫操作控制，對于讀數據，往往只能訪問到修改前的數據，這部分數據常常被稱為”dirty”或臟數據。在現實中，我們常常是有這樣的需求，當A進行寫操作時候，期望B不要讀數據，是對讀行為的控制。
這樣保證并發的時候不要出現B查的時候有，但是這個過程正好是A進行寫操作的過程，雖然加鎖防止并發寫，但是卻把對于B來說他在此過程中所看到的數據將被修改，即等A完成寫操作的時候,B讀的數據將被丟棄，這樣說來B讀到的數據應該是臟數據，或是無效數據，除非A的動作因為某些原因導致事務回滾，操作失敗，這樣現實數據結果和B看到的一致的時候，才斷定B看到的是有效數據，而不是臟數據或是無效數據。
【編輯推薦】
