1. 故事背景：
mysql數據遷移到oracle，其中有個表名叫“bil_vip”，有10萬條記錄，遷移后檢查發現oracle數據庫只插入34464條記錄，程序執行過程沒有發現任何錯誤。修改數據庫連接代碼向mysql插入10萬條記錄，結果都插入OK。
批量插入使用spring jdbctemplate.batchUpdate(sql, new BatchPreparedStatementSetter());方法，該方法的核心是PreparedStatement的executeBatch方法。
2. 繼續實驗：
新建一個Test表，只有一個name字段做實驗。
拋棄jdbctemplate，直接使用PreparedStatement做實驗，結果和jdbcTemplate是一樣的，實驗證明總是會丟失65536條記錄。
oracle 驅動的問題？換了最新driver，還是不行。繼續探索....
3. 希望之光：
早上發了個消息向大家征求思路，繼中說了一句分批處理，點亮了我的思路。按照繼中提供思路，每1萬條記錄一批，分多批發送給Oracle。
結果喜出望外，10萬條記錄全部插入成功。但是"65536"這個數字是什么意思呢......
在網上搜索文章發現，這個65536是一個bug。當PreparedStatement批量處理正好65536個記錄時候，程序會掛死。我試了一下真的掛死了，太嚇人了，這坑夠深的。
4. 解決方案：
spring jdbctemplate還是很好用的，而且業務已經被我封裝了，如果使用PreparedStatement意味著多了一個處理分支，以后維護會很麻煩。
我新建一個MyJdbcTemplate類，繼承 jdbctemplate類，并覆蓋了batchUpdate方法。這下舒服了，系統又恢復了整潔。
5. ★ 結論和收獲：
ü 有事多思考，多請教身邊同事。
ü 堅持Open-close原則(Open for extension, Closed for modification)會系統更好的擴展，非常容易維護，關鍵是要堅持這個原則，如果我因為一個特殊分支使用了PreparedStatement，這樣勢必破壞了這個原則，日后的維護必然會很麻煩。
ü 基于oracle數據如果使用jdbc批量，一定要分批發送數據oracle，否則正好發一個65536系統就掛死，大于65536數據就丟失，杯具呀......
6. 題目何以為“血案”：
周二打球回家就想這個問題，打開筆記本調試，不知不覺搞到很晚，影響媳婦睡覺（媳婦早上5:30上班），被痛罵一頓，趕緊上床睡覺，我媳婦氣的不行，手痛砸了一下床板（我們的床撤掉了床墊，只有床架和木板），床一下子塌了，把媳婦嚇壞了，把我腿弄傷了一塊，唉，“血案”呀。