資料庫為了實現併發控制通常會採用加鎖的方法。而鎖通常分為兩類：樂觀鎖和悲觀鎖。在某篇文章中看到這是從使用者的角度來看的。如果從資料庫實現來看，則好像是分成共享鎖（s鎖）和獨佔鎖（x）。在這裡只談一下我對樂觀鎖和悲觀鎖的一些個人理解。
樂觀鎖的出發點是相信併發操作發生衝突的概率比較少，即兩個使用者同時對一條資料進行修改的概率。這樣每當使用者要修改一條資料，並且加了樂觀鎖的話，其他使用者還是可以獲取該資料，並且也可以修改，但是只有第乙個使用者的提交是有效的，其他使用者的提交則會報錯，告訴使用者你要修改的資料已經被其他使用者修改了。
悲觀鎖則剛好相反，認為併發操作衝突的概率比較大。每次要更改資料的就加鎖（讀的時候加鎖實際上沒有太大的意義），這樣其他使用者想要修改資料的時候只能是等到加鎖的使用者釋放鎖才行。
顯然樂觀鎖的效率要高於悲觀所。因此在效率很重要而併發不是那麼嚴格的時候通常會採用樂觀鎖。
有人可能不清楚加鎖跟事務之間有什麼關係。其實資料庫為在自動根據使用者設定的隔離等級給事務加相應的鎖。
資料庫鎖 樂觀鎖 悲觀鎖理解
參考 mysql innodb中，樂觀鎖 悲觀鎖 共享鎖 排它鎖 行鎖 表鎖 死鎖概念的理解 樂觀鎖最簡單的實現就是在表中加乙個版本號欄位如version，每次新增設定為1，更新的時候檢查版本號是否一致，如果不一致就更新失敗。版本一致才能更新，然後將版本號 1。首先資料庫需要關閉自動提交功能，或者說...
資料庫中樂觀鎖和悲觀鎖的理解
鎖 locking 業務邏輯的實現過程中，往往需要保證資料訪問的排他性。如在金融系統的日終結算 處理中，我們希望針對某個 cut off 時間點的資料進行處理，而不希望在結算進行過程中 可能是幾秒種，也可能是幾個小時 資料再發生變化。此時，我們就需要通過一些機 制來保證這些資料在某個操作過程中不會被...
資料庫的樂觀鎖和悲觀鎖
悲觀鎖 假定會發生併發衝突，遮蔽一切可能違反資料完整性的操作，假設資料肯定會衝突，所以在資料開始讀取的時候就把資料鎖定住。資料鎖定 資料將暫時不會得到修改 樂觀鎖 假設不會發生併發衝突，只在提交操作時檢查是否違反資料完整性。資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測，如果發現衝突了，則...