如果你研究到庫存系統的開發問題時，你就會從這裡出發考慮了一些有關庫存信息中需要的操作和，一般的情況下會遇到的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看到的是有效數據，而不是髒數據或是無效數據。
