今天項目中有個需求，需要使用定時器去每天定時備份一些數據，數據量一天大概10多萬條數據，使用的是MySQL
數據庫，然後再功能實現後，發現備份的速度非常慢，10w多條數據要10多分鐘，而且還使用了JDBC的批處理，感
覺不可能這麼慢，一定是哪裏出了問題！
最初推斷有可能是以下原因：1.表中創建的一些字段的索引影響了速度；
2.源數據庫和目標數據庫都是在阿里雲的兩臺服務器上的，而程序暫且是跑在我本地主機上的，由於網速，距離等原
因影響了批處理速度；
針對第一點原因，我刪除了表中所有的索引，經測試還是如此慢，此原因被排除；
針對第二點原因，我在我本地主機創建了一個目標數據庫，但測試結果還是很失望；
到底是哪裏出了問題呢，一時找不到任何頭緒，只能在網上查查看大家是否有和我一樣遇到類似的問題，有人說是數
據庫類型InnoDB和MyISAM的問題，我們都知道，InnoDB和MyISAM的最大區別就是：
InnoDB和MyISAM是許多人在使用MySQL時最常用的兩個表類型，這兩個表類型各有優劣，視具體應用而定。基本的差別爲：MyISAM類型不支持事務處理等高級處理，而InnoDB類型支持。MyISAM類型的表強調的是性能，其執行數度比InnoDB類型更快，但是不提供事務支持，而InnoDB提供事務支持已經外部鍵等高級數據庫功能。
我這裏表類型使用的是InnoDB，代碼中也沒有使用到事務，於是就換爲MyISAM類型測試了一下，結果出乎意料，
確實快了很多，10w多條數據備份7592ms，原來的是需要10多分鐘，都不是一個量級的啊，難道真的是因爲數據庫
表引擎（InnoDB,MyISAM）不同導致的備份速度是差別嗎，但這速度也差的太多了吧！
繼續在網上找相關資料，結果還真找到了和我遇到一樣問題的，就是在數據庫連接的URL中添加了參數
rewriteBatchedStatements=true，測試結果：
MyISAM：869ms
InnoDB：5540ms
下面是解決這個問題的總結：
爲了提高大量數據的入庫效率於是想到了批處理，可是在實際測試過程中發現用批量操作後入庫的效率並沒有什麼明
顯的提高，經搜索相關資料和自己的實際測試得出以下一些結論，以供大家參考。
一、基本結論
1.滿足相應的前提條件後（見後面的詳細描述），mysql執行批量插入大量數據的效率還是非常高的。
2.是否支持批量插入數據和表自身是否支持事務沒有必要的關聯關係，不過從測試結果看非事務型（MyISAM）比事
務型（InnoDB）效率要高點。
MySQL實現批量插入數據的前提條件：
1.需要在url中添加參數rewriteBatchedStatements=true
比如:jdbc:mysql://192.168.8.15:3306/demo?
rewriteBatchedStatements=true&useUnicode=true&characterEncoding=UTF-8；
2.MySQL的版本需要3.1.13+才支持參數rewriteBatchedStatements（目前基本用的都是5.0+，本人測試用的是
5.0.77）；
3.需要MySQL的JDBC的驅動支持（本人測試過mysql-connector-java-5.1.13、mysql-connector-java-5.1.16、
mysql-connector-java-5.1.17均支持）；
二、測試數據對比
| 測試對比 | 批量插入(ms) | 普通插入(ms) | ||
| 參數true | 參數false | 參數true | 參數false | |
| MyISAM | 1633 | 36775 | 34913 | 43610 |
| InnoDB | 2374 | 42427 | 43531 |
34678 |
Tips：
1.上表格中的參數true/false是指URL中的 rewriteBatchedStatements
2.參數rewriteBatchedStatements的值對普通插入是沒有影響的，該參數只在批操作時有效
3.測試時同樣的操作耗時有浮動的，普通操作大概在36-45秒之間（這裏是貼出只是某一次的完成測試結果），本次
測試的重點是關注批量插入和普通插入的效率，從上圖可以明顯得出結論。
從上面的數據對比圖中可見：增加參數後批量插入數據的效率明顯提高了很多。
