關於併發的問題

     實際項目開發中遇到這樣的一個問題，主表的讀取和副表的讀取，前者爲表更新以前的結果，後者爲表更新以後的結果。由此懷疑mysql事務提交以後表更新不是按照表的語句先後順序執行，而是按照mysql的自身的優化機制（並沒有實證）來決定語句前後的，可是事務未執行完畢以前對外部是不可見，要不就回出現髒讀，因此上述即便成立，也不會形成該問題。

事情的原因是這樣：外部應用在提交業務數據的變動以前，會先調用api讀取上述的兩個表，進行必定的運算，而後調用另外一個api寫入主副表信息。因爲併發處理很差，致使有幾回的讀寫。按照業務邏輯主表和副表是一次事務操做寫入，另外主表在前，副表在後。因爲併發的緣由，致使出現了一個奇怪的現象，在第二次的併發讀寫中，外部應用獲得了這樣的結果：主表爲更新前的結果，副表爲更新以後的結果，由此懷疑事務的表操做順序，貌似事務先執行了副表，後執行了主表。

後續的分析肯定了最終的緣由以下：

　　外部api讀寫主副進行計算，在讀取的時候上一次寫操做還未完成，因此主表讀取的數據爲舊數據，以後寫操做完成了以後，外部api讀取至副表信息，因此讀取到新的副表信息。其實外部api讀取主副表只是一次（接口內部實現爲先讀取主信息，再讀取副表），因此形成該異常。

　　總結：①事務依次執行的重要，最好鎖機制（緩存或文本鎖......）②作好數據寫入的校驗......