數(shù)據(jù)庫update時切忌這樣干，這樣干是什么?請隨我來看看。

早些時候，客戶發(fā)來這樣一段文字“XX的，XXXXXXXX有個10萬沒到賬，幫加上去。”我馬上動手查看數(shù)據(jù)庫，尋找原因，隨后回復了這樣一句話“開玩笑吧”。雖然之前發(fā)生過類似這樣的問題，但都是小額資金，就手動在數(shù)據(jù)庫里加了，遇到這么大的資金還是頭一次，于是我加緊翻看數(shù)據(jù)庫記錄的節(jié)奏。

我發(fā)現(xiàn)用戶的入金記錄的確已經(jīng)是審核通過狀態(tài)，而用戶的可用資金卻沒有加上，這已經(jīng)讓人意外了。

接著我查看代碼，并沒有發(fā)現(xiàn)邏輯上的問題，這又讓我感到迷茫。

再翻看日志，發(fā)現(xiàn)沒有任何異常，好吧，感覺被設了局一樣。

回頭想想，這種情況并不多見，程序在多數(shù)情況下并沒有這種情況，一切正常。這糟了，沒有錯誤日志就是最大的錯誤。

靜下心來，我想有可能是事務出現(xiàn)的問題，因為對于資金表，同一個用戶的資金在同一個時間點是可能同時被更新的，我猜想，是入金記錄先插入了出入金記錄表，等到更新資金表的時候被鎖住，事務超時后插入的記錄沒有回滾，于是我通過這樣的方式來證明一下。

START TRANSACTION;

INSERT INTO record VALUES(1,123);

UPDATE money SET money = money + 10;

COMMIT;

START TRANSACTION;

UPDATE money SET money = money + 100;

COMMIT;

通過手動控制事務鎖，發(fā)現(xiàn)不是我想的那樣。然后我又試了試下面這種方式：

START TRANSACTION;

UPDATE money SET money = money + 10;

INSERT INTO record VALUES(1,123);

COMMIT;

START TRANSACTION;

UPDATE money SET money = money + 100;

COMMIT;

發(fā)現(xiàn)兩者的效果是一樣的，事務都會回滾。

這個時候，我的思路被禁錮了，我和同事討論起來，看看他有什么想法，經(jīng)過一番思想斗爭后，果然同事還是給出了他的想法，我深感贊同。

MoneyUser moneyUser = moneyUserMapper.selectByPrimaryKey(members.getUid());

// 凍結資金-出金金額

moneyUser.setFrozenl(moneyUser.getFrozen().subtract(moneyTransfer.getount()));

// 可用資金+出金金額

moneyUser.setTotaaymoney(moneyUser.getTotalpayey().add(moneyTransfer.getount()));

this.moneyUserMapper.updateByPrimaryKey(moneyUser);

這樣的代碼在出現(xiàn)并發(fā)的時候，獲取moneyUser對象的時候，其中的凍結資金和可用資金加入都是0，那么兩個并發(fā)在update的時候，兩個都執(zhí)行了，但是起初的凍結資金和可用資金相同，就會導致有一筆資金沒有加上。

調試的時候更容易發(fā)現(xiàn)這個問題。OH，my 噶，真是個大問題，還出在資金的問題時，我真慶幸這個問題發(fā)生的頻率不夠高。不過我到底是應該慶幸還是不慶幸呢，也許次數(shù)發(fā)生的多起來的時候，我就更容易來反思來找出問題的癥結所在。

那么問題怎么解決呢?

UPDATE moneser

SET

frozapital = frozpital - #{amount,jdbcType=DECIMAL},

totaloney = totaloney + #{amount,jdbcType=DECIMAL}

WHERE uid = #{uid,jdbcType=INTEGER}

通過在sql語句中進行字段的更新操作，而不是在Java類中，因為mysql本身是會有這方面的處理方式的。

這個問題，之前領導有建議我在update數(shù)據(jù)的時候盡量在sql語句中加入，而不是類字段中做處理。

總結：這個問題，如果你不經(jīng)意的話，很容易發(fā)生這個問題，我當初就沒有這樣的意識，真是可悲可嘆!

更多信息請查看IT技術專欄