.背景
使用者修改布局時，需要批量更新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語句
橫坐标： 一次批量更新的條數。縱坐标：更新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();