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

對批量的性能進行了測試，優化。過程如下。

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

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

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

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

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

查看包的內容可以發現，這條請求里，封裝了30條update語句

橫坐標： 一次批量更新的條數?？v坐標：更新100次所用時間(ms)

可見，當批量條數增加時，rewriteBatchedStatements=true的性能有很大優勢。即使數量少時，也還是有一定優勢。

結論：

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

JDBC Driver版本從5.0.4升級到5.1.17。

連接屬性中加入rewriteBatchedStatements=true參數

附：

測試環境：

mysql JDBC 3.0.4/3.1.17。

客戶端: 普通PC機。

連接池數: 1-10。

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

批量更新主要代碼：

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

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

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

}

mmpSqlMapClient.executeBatch();

mmpSqlMapClient.commitTransaction();

轉自：http://hidba.org/?p=369

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。