一、我們遇到了什么問題

在標準SQL里面，我們通常會寫下如下的SQL insert語句。

很顯然,在MySQL中，這樣的方式也是可行的。但是當我們需要批量插入數據的時候，這樣的語句卻會出現性能問題。例如說，如果有需要插入100000條數據，那么就需要有100000條insert語句，每一句都需要提交到關系引擎那里去解析，優化，然后才能夠到達存儲引擎做真的插入工作。

正是由于性能的瓶頸問題，MYSQL官方文檔也就提到了使用批量化插入的方式，也就是在一句INSERT語句里面插入多個值。即，

這樣的做法確實也可以起到加速批量插入的功效，原因也不難理解，由于提交到服務器的INSERT語句少了，網絡負載少了，最主要的是解析和優化的時間看似增多，但是實際上作用的數據行卻實打實地多了。所以整體性能得以提高。根據網上的一些說法，這種方法可以提高幾十倍。

然而，我在網上也看到過另外的幾種方法，比如說預處理SQL，比如說批量提交。那么這些方法的性能到底如何？本文就會對這些方法做一個比較。

二、比較環境和方法

我的環境比較苦逼，基本上就是一個落后的虛擬機。只有2核，內存為6G。操作系統是SUSI linux，MYSQL版本是5.6.15。

可以想見，這個機子的性能導致了我的TPS一定非常低，所以下面的所有數據都是沒有意義的，但是趨勢卻不同，它可以看出整個插入的性能走向。

由于業務特點，我們所使用的表非常大，共有195個字段，且寫滿（每個字段全部填滿，包括varchar）大致會有略小于4KB的大小，而通常來說，一條記錄的大小也有3KB。

由于根據我們的實際經驗，我們很肯定的是，通過在一個事務中提交大量INSERT語句可以大幅度提高性能。所以下面的所有測試都是建立在每插入5000條記錄提交一次的做法之上。

最后需要說明的是，下面所有的測試都是通過使用MYSQL C API進行的，并且使用的是INNODB存儲引擎。

三、比較方法

理想型測試（一）——方法比較

目的：找出理想情況下最合適的插入機制

關鍵方法：

1. 每個進/線程按主鍵順序插入

2. 比較不同的插入方法

3. 比較不同進/線程數量對插入的影響

*“普通方法”指的是一句INSERT只插入一個VALUE的情況。

*“預處理SQL”指的是使用預處理MYSQL C API的情況。

* “多表值SQL(10條）”是使用一句INSERT語句插入10條記錄的情況。為什么是10條？后面的驗證告訴了我們這樣做性能最高。

結論，很顯然，從三種方法的趨勢上來看，多表值SQL(10條）的方式最為高效。

理想型測試（二）——多表值SQL條數比較

很顯然，在數據量提高的情況下，每條INSERT語句插入10條記錄的做法最為高效。

理想型測試（三）——連接數比較

結論：在2倍與CPU核數的連接和操作的時候，性能最高

一般性測試—— 根據我們的業務量進行測試

目的：最佳插入機制適合普通交易情況？

關鍵方法：

1. 模擬生產數據(每條記錄約3KB)

2. 每個線程主鍵亂序插入

很顯然，如果是根據主鍵亂序插入的話，性能會有直線下降的情況。這一點其實和INNODB的內部實現原理所展現出來的現象一致。但是仍然可以肯定的是，多表值SQL(10條）的情況是最佳的。

壓力測試

目的：最佳插入機制適合極端交易情況？

關鍵方法：

1. 將數據行的每一個字段填滿（每條記錄約為4KB）

2. 每個線程主鍵亂序插入

結果和我們之前的規律類似，性能出現了極端下降。并且這里驗證了隨著記錄的增大（可能已經超過了一個page的大小，畢竟還有slot和page head信息占據空間），會有page split等現象，性能會下降。

四、結論

根據上面的測試，以及我們對INNODB的了解，我們可以得到如下的結論。

?采用順序主鍵策略（例如自增主鍵，或者修改業務邏輯，讓插入的記錄盡可能順序主鍵）

?采用多值表（10條）插入方式最為合適

?將進程/線程數控制在2倍CPU數目相對合適

五、附錄

我發現網上很少有完整的針對MYSQL 預處理SQL語句的例子。這里給出一個簡單的例子。

/*====================================================*/

------------------------------------------------------------------------

轉自：http://www.cnblogs.com/aicro/p/3851434.html