第一類丟失更新(回滾丟失，lost update)
a事務撤銷時，把已經提交的b事務的更新資料覆蓋了。這種錯誤可能造成很嚴重的問題，通過下面的賬戶取款轉賬就可以看出來：
時間取款事務a
轉賬事務b t1
開始事務
t2
開始事務t3
查詢賬戶餘額為1000元
t4 查詢賬戶餘額為1000元 t5
匯入100元把餘額改為1100元 t6
提交事務t7
取出100元把餘額改為900元
t8 撤銷事務
t9 餘額恢復為1000
元（丟失更新）
a事務在撤銷時，「不小心」將b事務已經轉入賬戶的金額給抹去了。
sql92沒有定義這種現象，標準定義的所有隔離界別都不允許第一類丟失更新發生。
第二類丟失更新(覆蓋丟失/兩次更新問題，second lost update)
a事務覆蓋b事務已經提交的資料，造成b事務所做操作丟失： 時間
轉賬事務a
取款事務b t1
開始事務t2
開始事務
t3 查詢賬戶餘額為1000元 t4
查詢賬戶餘額為1000元
t5 取出100元把餘額改為900元 t6
提交事務t7
匯入100元
t8 提交事務
t9 把餘額改為1100
元（丟失更新）
上面的例子裡由於支票轉賬事務覆蓋了取款事務對存款餘額所做的更新，導致銀行最後損失了100元，相反如果轉賬事務先提交，那麼使用者賬戶將損失100元。
第二類丟失更新，實際上和不可重複讀是同一種問題。
有些系統中第二類丟失更新可能就影響很大了，舉個簡單的例子：
財務系統加工資，若公司本次調薪決定給員工張三加1k人民幣，財務部兩名操作人員a和b，過程情況若是這樣的：
1）a操作員在應用系統的頁面上查詢出張三的薪水資訊，然後選擇薪水記錄進行修改，開啟修改頁面但a突然有事離開了，頁面放在那沒有做任何的提交。
2）這時候b操作員同樣在應用中查詢出張三的薪水資訊，然後選擇薪水記錄進行修改，錄入增加薪水額1000，然後提交了。
3）這時候a操作員回來了，在自己之前開啟的薪水修改頁面上也錄入了增加薪水額1000，然後提交了。
其實上面例子操作員a和b只要一前一後做提交，悲劇就出來了。後台修改薪水的sql：update 工資表 set salary = salary + 增加薪水額 where staff_id = 『員工id』。這個過程走下來後結果是：張三開心了這次漲了2k，操作員a和b都鬱悶了。
解決思路：
基本兩種思路，一種是
悲觀鎖，另外一種是
樂觀鎖；
簡單的說就是一種假定這樣的問題是高概率的，最好一開始就鎖住，免得更新老是失敗；另外一種假定這樣的問題是小概率的，最後一步做更新的時候再鎖住，免得鎖住時間太長影響其他人做有關操作。
解決方案1（悲觀鎖）
以上面的例子來說明，在彈出修改工資的
頁面初始化時（這種情況下一般會去從資料庫查詢出來），在這個初始化查詢中使用select ...for update nowait， 通過新增for update nowait語句，將這條記錄鎖住，避免其他使用者更新，從而保證後續的更新是在正確的狀態下更新的。然後在保持這個鏈結的狀態下，在做更新提交。當然這個有個前提就是要保持鏈結，就是要對鏈結要占用較長時間，這個在現在web系統高併發高頻率下顯然是不現實的。
在修改工資這個頁面做提交時先查詢下，當然這個查詢必須也要加鎖（select ...for update nowait），有人會說，在這裡做個查詢確認記錄是否有改變不就行了嗎，是的，是要做個確認，只是你不加for update就不能保證你在查詢到更新提交這段時間裡這條記錄沒有被其他會話更新過，所以這種方式也需要在查詢時鎖定記錄，保證在這條記錄沒有變化的基礎上再做更新，若有變化則提示告知使用者。
解決方案2（樂觀鎖）
a.舊值條件（前映象）法：
就是在sql更新時使用舊的狀態值做條件，sql大致如下 update table set col1 = newcol1value, col2 = newcol2value…. where col1 = oldcol1value and col2 = oldcol2value….，在上面的例子中我們就可以把當前工資作為條件進行更新，如果這條記錄已經被其他會話更新過，則本次更新了0行，這裡我們應用系統一般會做個提示告知使用者重新查詢更新。這個取哪些舊值作為條件更新視具體系統實際情況而定。（這種方式有可能發生阻塞，如果應用其他地方使用悲觀鎖法長時間鎖定了這條記錄，則本次會話就需要等待，所以使用這種方式時最好統一使用樂觀鎖法。）
其實這種方式是乙個特殊化的前映象法，就是不需要使用多個舊值做條件，只需要在表上加乙個版本列，這一列可以是number或 date/timestamp列，加這列的作用就是用來記錄這條資料的版本（在表設計時一般我們都會給每個表增加一些number型和date型的冗餘字段，以便擴充套件使用，這些冗餘字段完全可以作為版本列用），在應用程式中我們每次操作對版本列做維護即可。在更新時我們把上次版本作為條件進行更新。
c.使用校驗和法（不推薦）
d.使用ora_rowscn法（不推薦）
結論：
綜上所述，我們對丟失更新問題建議採取上面的悲觀鎖b方法或樂觀鎖b方法（紅字型已標註），其實這兩種方式的本質都一樣，都是在更新提交時做一次查詢確認在更新提交，我個人覺得都是樂觀的做法，區別在於悲觀鎖b方法是通過select..for
update方式，這個可能會導致其他會話的阻塞，而樂觀鎖b方法需要多乙個版本列的維護。
個人建議：在使用者併發數比較少且衝突比較嚴重的應用系統中選擇悲觀鎖b方法，其他情況首先樂觀鎖版本列法。
資料庫第一類第二類丟失更新
第一類丟失更新 回滾丟失，lost update a事務撤銷時，把已經提交的b事務的更新資料覆蓋了。這種錯誤可能造成很嚴重的問題，通過下面的賬戶取款轉賬就可以看出來 a事務在撤銷時，不小心 將b事務已經轉入賬戶的金額給抹去了。sql92沒有定義這種現象，標準定義的所有隔離級別都不允許第一類丟失更新發...
第一類和第二類斯特林數
第一類斯特林數定義如下 s 1 n,k 表示 n 個元素組成 k 個圓排列的方案數。其中 n 個元素的圓排列定義為 n 個元素圍成一圈的排列，兩個圓排列本質相同當且僅當兩個圓排列以任意方式旋轉之後相同。那麼我們可以得到第一類斯特林數的遞推公式 s 1 n,k s 1 n 1,k 1 n 1 cdot...
資料庫隔離級別，第二類更新丟失
乙個事務中可以讀到別的事務任何資料，包括已提交 和 未提交的髒資料 乙個事務中只能讀到其他事物已經提交的資料 乙個事務在本事務提交之前讀到的資料不會受其它事務crud的影響，所以前後讀的資料是一致的，可以重複讀 注意 實際上這個可重複讀只是針對讀 select 所看到的的資料是可以重複讀的，僅此而已...