實際專案開發中遇到這樣的乙個問題，主表的讀取和副表的讀取，前者為表更新之前的結果，後者為表更新之後的結果。由此懷疑mysql事務提交之後表更新不是按照表的語句前後順序執行，而是按照mysql的自身的優化機制（並無實證）來決定語句先後的，但是事務未執行完畢之前對外部是不可見，要不就回出現髒讀，所以上述即使成立，也不會造成該問題。
事情的緣由是這樣：外部應用在提交業務資料的變更之前，會先呼叫api讀取上述的兩個表，進行一定的運算，然後呼叫另乙個api寫入主副表資訊。由於併發處理不好，導致有幾次的讀寫。按照業務邏輯主表和副表是一次事務操作寫入，另外主表在前，副表在後。由於併發的原因，導致出現了乙個奇怪的現象，在第二次的併發讀寫中，外部應用得到了這樣的結果：主表為更新前的結果，副表為更新之後的結果，由此懷疑事務的表操作順序，貌似事務先執行了副表，後執行了主表。
後續的分析確定了最終的原因如下：
外部api讀寫主副進行計算，在讀取的時候上一次寫操作還未完成，所以主表讀取的資料為舊資料，之後寫操作完成了之後，外部api讀取至副表資訊，所以讀取到新的副表資訊。其實外部api讀取主副表只是一次（介面內部實現為先讀取主資訊，再讀取副表），所以造成該異常。
總結：①事務依次執行的重要，最好鎖機制（快取或文字鎖......）②做好資料寫入的校驗......
關於執行緒的問題 併發？
前言 在執行測試用例的時候，經常會考慮到併發執行測試用例的情況。通常會使用testng的套件來解決多個用例的執行，但在testng的套件執行中，會有這樣乙個問題，我在乙個testng的case裡新建兩個webdriver，再做操作，他們就會衝突。然後其中乙個會死掉。如果我們直接用testng的多執行...
Mysql關於事務併發帶來的問題
mysql從5.5.8開始，innodb就是預設的儲存引擎，innodb最大的特點是 支援事務 支援行級鎖。既然支援事務，那麼就會有處理併發事務帶來的問題 更新丟失 髒讀 不可重複讀 幻讀 相應的為了解決這四個問題，就產生了事務隔離級別 未提交讀 read uncommitted 已提交讀 read...
關於併發使用者與集合點的問題
q 併發使用者數和集合點有必然聯絡嗎？在效能測試中必須使用集合點來測試嗎？a 併發使用者數，顧名思義，就是同時操作的使用者，這裡的 操作 可以指對系統真正的操作，也可以只是連線 此時通常叫作 併發連線數 而集合點是一種特殊情況下的併發，多用於測試系統在瞬間加壓的表現。因此，併發使用者數和集合點有聯絡...