用戶修改布局時，需要批量更新mysql的xxxx_layout_xxxx表。批量操作的數(shù)據(jù)量是2-30條/次。批量操作是這次項目在技術(shù)上比較關(guān)鍵的一個點，之前批量操作做過性能上的測試，mysql端問題不大，7000+tps，Java端的效率有些差，有優(yōu)化空間。

對批量的性能進行了測試，優(yōu)化。過程如下。

經(jīng)測試，批量更新30條記錄的時間是35ms。由于數(shù)據(jù)在mysql服務(wù)端中會有內(nèi)存緩存，批量更新30條的時間用了35ms，感覺有些長，試圖找出原因。

使用截包工具(這里用的ethereal)，抓取mysql的數(shù)據(jù)包，下面是一次批量更新的數(shù)據(jù)包:

可以看出，批量更新時，每條update語句都去mysql請求了一次。并沒有打包發(fā)給mysql。這種批量的效率肯定不會高。同樣方法試了下oracle數(shù)據(jù)庫，oracle驅(qū)動做的就很好，一次批量是打包在同一個請求中，是真正的批量提交，效率自然比mysql高。

找了些資料，發(fā)現(xiàn)mysql默認(rèn)情況確實是不支持batch。為了解決上面的問題，需要給JDBC連接加上參數(shù)rewriteBatchedStatements=true，并且jdbc driver需要升級到5.1.8以上才支持這個參數(shù)。

增加參數(shù)rewriteBatchedStatements=true，driver版本升到5.1.17后，再次測試，批量更新30條的時間從35ms降到了11ms。截包后，可以看出底層的機制，已經(jīng)變成批量提交：

查看包的內(nèi)容可以發(fā)現(xiàn)，這條請求里，封裝了30條update語句

橫坐標(biāo)： 一次批量更新的條數(shù)。縱坐標(biāo)：更新100次所用時間(ms)

可見，當(dāng)批量條數(shù)增加時，rewriteBatchedStatements=true的性能有很大優(yōu)勢。即使數(shù)量少時，也還是有一定優(yōu)勢。

結(jié)論：

使用rewriteBatchedStatements=true參數(shù)，對批量操作，性能有較大提高，從官方解釋上看，對普通操作沒有影響。 從網(wǎng)上資料和自己的測試上看，暫時沒有發(fā)現(xiàn)rewriteBatchedStatements=true參數(shù)Driver版本5.1.17的問題。 因此，本項目中計劃采取下面優(yōu)化措施：

JDBC Driver版本從5.0.4升級到5.1.17。

連接屬性中加入rewriteBatchedStatements=true參數(shù)

附：

測試環(huán)境：

mysql JDBC 3.0.4/3.1.17。

客戶端: 普通PC機。

連接池數(shù): 1-10。

10線程并發(fā)，批量更新30條記錄(索引有效)，循環(huán)更新100次。

批量更新主要代碼：

mmpSqlMapClient.startTransaction(); // 使用事務(wù)

mmpSqlMapClient.startBatch(); // 批量提交

for?(ChannelLayoutDO channelLayout: userChannelLayoutList) {????????? ??? mmpSqlMapClient.update(“UserChannelLayoutDAO.updateSort”, channelLayout);

}

mmpSqlMapClient.executeBatch();

mmpSqlMapClient.commitTransaction();

轉(zhuǎn)自：http://hidba.org/?p=369

總結(jié)

以上是生活随笔為你收集整理的mysql数据没有真正提交,转MySQL 批量提交优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。