數(shù)據(jù)庫update時切忌這樣干，這樣干是什么?請隨我來看看。
早些時候，客戶發(fā)來這樣一段文字“XX的，XXXXXXXX有個10萬沒到賬，幫加上去?！蔽荫R上動手查看數(shù)據(jù)庫，尋找原因，隨后回復了這樣一句話“開玩笑吧”。雖然之前發(fā)生過類似這樣的問題，但都是小額資金，就手動在數(shù)據(jù)庫里加了，遇到這么大的資金還是頭一次，于是我加緊翻看數(shù)據(jù)庫記錄的節(jié)奏。
我發(fā)現(xiàn)用戶的入金記錄的確已經(jīng)是審核通過狀態(tài)，而用戶的可用資金卻沒有加上，這已經(jīng)讓人意外了。
接著我查看代碼，并沒有發(fā)現(xiàn)邏輯上的問題，這又讓我感到迷茫。
再翻看日志，發(fā)現(xiàn)沒有任何異常，好吧，感覺被設(shè)了局一樣。
回頭想想，這種情況并不多見，程序在多數(shù)情況下并沒有這種情況，一切正常。這糟了，沒有錯誤日志就是最大的錯誤。
靜下心來，我想有可能是事務(wù)出現(xiàn)的問題，因為對于資金表，同一個用戶的資金在同一個時間點是可能同時被更新的，我猜想，是入金記錄先插入了出入金記錄表，等到更新資金表的時候被鎖住，事務(wù)超時后插入的記錄沒有回滾，于是我通過這樣的方式來證明一下。
START TRANSACTION;
INSERT INTO record VALUES(1,123);
UPDATE money SET money = money + 10;
COMMIT;
START TRANSACTION;
UPDATE money SET money = money + 100;
COMMIT;
通過手動控制事務(wù)鎖，發(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)兩者的效果是一樣的，事務(wù)都會回滾。
這個時候，我的思路被禁錮了，我和同事討論起來，看看他有什么想法，經(jīng)過一番思想斗爭后，果然同事還是給出了他的想法，我深感贊同。
MoneyUser moneyUser = moneyUserMapper.selectByPrimaryKey(members.getUid());
// 凍結(jié)資金-出金金額
moneyUser.setFrozenl(moneyUser.getFrozen().subtract(moneyTransfer.getount()));
// 可用資金+出金金額
moneyUser.setTotaaymoney(moneyUser.getTotalpayey().add(moneyTransfer.getount()));
this.moneyUserMapper.updateByPrimaryKey(moneyUser);
這樣的代碼在出現(xiàn)并發(fā)的時候，獲取moneyUser對象的時候，其中的凍結(jié)資金和可用資金加入都是0，那么兩個并發(fā)在update的時候，兩個都執(zhí)行了，但是起初的凍結(jié)資金和可用資金相同，就會導致有一筆資金沒有加上。
調(diào)試的時候更容易發(fā)現(xiàn)這個問題。OH，my 噶，真是個大問題，還出在資金的問題時，我真慶幸這個問題發(fā)生的頻率不夠高。不過我到底是應該慶幸還是不慶幸呢，也許次數(shù)發(fā)生的多起來的時候，我就更容易來反思來找出問題的癥結(jié)所在。
那么問題怎么解決呢?
UPDATE moneser
SET
frozapital = frozpital - #{amount,jdbcType=DECIMAL},
totaloney = totaloney + #{amount,jdbcType=DECIMAL}
WHERE uid = #{uid,jdbcType=INTEGER}
通過在sql語句中進行字段的更新操作，而不是在Java類中，因為mysql本身是會有這方面的處理方式的。
這個問題，之前領(lǐng)導有建議我在update數(shù)據(jù)的時候盡量在sql語句中加入，而不是類字段中做處理。
總結(jié)：這個問題，如果你不經(jīng)意的話，很容易發(fā)生這個問題，我當初就沒有這樣的意識，真是可悲可嘆!