ref : https://medium.com/dean-lin/真正理解資料庫的悲觀鎖-vs-樂觀鎖-2cabb858726d

爲什麼要了解這個呢？

我相信工作一段時間，一定會遇到資料被重複異動、覆蓋的情況，初學者可能想說，那就多設where條件啊，但這不能根本的解決這個議題，不過設定where條件想法，已經有點接觸這個議題了．

以前常聽同事，提到一些關鍵字 dead lock 、red lock 、row lock 都會一頭霧水，發生dead lock 事件的時候，也不能體會他們在緊張什麼，所幸現在知道的事情多了，就想說把這個觀念給記錄下來吧

所以什麼是樂觀鎖 vs 悲觀鎖 ？

樂觀鎖、悲觀鎖是種概念，主要指的是針對DB table 欄位異動的限制，解決資料出現不符合預期的異動

• 樂觀鎖
  • 允許多個 sql command 同時操作資料
  • 優點
    • 可以快速的完成異動
  • 缺點
    • 造成資料出現不合預期的結果
• 悲觀鎖
  • 一次只能一個 sql command 操作資料，其他 command 無法在資料正在被操作時異動，只能排隊等
  • 優點
    • 可以確保資料正確性
  • 缺點
    • 因為需要排隊異動，因此處理時間拉長

我對樂觀鎖、悲觀鎖的理解是，樂觀鎖就像是信任制，會給你條件讓你遵守，確保結果，悲觀鎖就是覺得人性本惡，所以必須用強制規定，確保結果

舉個爸爸零錢箱例子

家裡爸爸準備了共用零錢箱給家裡兩個小孩，裡頭固定有五百元．錢可以取用，但是當天晚上必須把錢補回500

如果爸爸採用樂觀鎖，制定規則

爸爸相信大家都會遵守規則，所以兩位可以隨時取用零錢，但是必須在當天晚上把拿走的補齊，讓零錢箱固定有500

如果爸爸採用悲觀鎖，制定規則

爸爸才不相信大家會乖乖把錢補進去，因此每個人取用零錢，必須寫下誰、在幾點幾分、拿走多少，反之亦然，一樣當天晚上零錢桶需有500

小結

用樂觀鎖，取用零錢的人可以自由取用、但相對的要做到軟性的要求，就是把拿走的補齊，此情況雖然方便快速，但肯定會有人性的忘記，導致結果不符合預期(晚上金額500)

用悲觀鎖，取用零錢的人，取用、歸還時，都需要強制完成紀錄的動作，否則不能達成目的，這相較樂觀鎖，是用強制力規範，確保結果符合預期，但相對的需要紀錄支出，本身就會耗費時間

然後呢？

其實在開發過程中，沒有什麼絕對，所以我們首先需要知道有這個選擇，然後根據當下的情境，選擇最適合的方案組合

樂觀鎖的情境，比較適用修改量不大、資料若真的有非預期異動，其損害也還能承受的情況

悲觀鎖的情境，比較適用有大量的修改量、資料不容許些微失誤的情況(金額交易)