Insert的性能為啥這么差

Insert的性能為啥這么差，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

最近發現單位某些系統的的插入性能不是很好，誠然知道物理存儲的性能不是很好，在關鍵系統都在使用SSD 的時代，我們還沒有進入SSD的懷抱。但另一個點，為什么有的地方使用費SSD 的設備，其實插入的性能還好，或者說如果換裝SSD 設備后，其實也看不出區別。 排除數據量小的問題，其實數據庫對插入的優化也是需要的。

那么我們分析一下，插入其中會遇到哪些問題，這里我們可能不會限定某種數據庫，而是大范圍的討論，當然有些問題可能是針對某些數據庫，這邊會有所體現。

1 問題， 我們是使用自增的方式 還是使用散列的方式進行數據的插入

其實這是一個好問題，有人說自增型的插入符合了某些數據庫的物理數據存放的屬性，所以查找快，有人說散列的方式插入快，我把KEY都打散，插入，一定比順序的方式好。

我個人其實對“一定”這個詞不是很有好感，活了這么多年，一定這個詞在我這屬于不靠譜的詞匯 LIST。

那到底是不是這樣，我們來進行分析，如果是自增的方式，在大量數據插入的時候，會出現熱點問題，我們現已MYSQL 為例

線程 1 

insert into table (......) values (.........),(.........).......

線程2

insert into table select .... from table 2

我們來看一下上面的語句，如果同時運行，而且我們還是用了MYSQL的 自增方式會出現什么問題。

對，自增主鍵的熱點，這也就是MYSQL 在5.5之前在大量數據插入的時候，被詬病的問題。那后來MYSQL 是怎么解決的，這里就要說到MYSQL的 自增的 三個參數，我們現在大部分選擇

innodb_autoinc_lock_mode = 2

這樣的選擇，有什么問題？顯而易見，ID 在大量的插入的時候，可能出現不連續的問題。 

我們通過上面的語句可以看到什么，一個插入的語句要使用 using where using temporary, 為什么？  大家可以思考一下這個問題，并且想想如果這個select后面的語句是大量的數據，對一個高頻詞運行效率優先的系統，是不是一件好事情。文章結尾會有一個簡單的說明。

另外我們需要考慮一下，如果我們不使用自增的方式，通過類似MONGODB 散列的方式生成主鍵插入， （其實還不是，類似UUID 這樣的東西才是散列），且我們這邊將MONGODB 的 OBJECT ID 視為散列（無序）。

MONGODB 中的主鍵主要是由幾個方面產生的，unix 時間，MONGODB的機器碼標識，一個隨機數，等等生成的，這里便宜一個話題，如果想使用雪花算法，可以考慮借鑒一下 MONGODB 的OBJECT_ID的生成方法，當然MONGODB的 OBJECT_ID 考慮了很多，所以對數以億萬的數據也不會有撞庫的風險。

以下就是MONGODB 的數據存儲的方式，這點方式和 HEAP 表的存儲方式類似，當然由于非事務性性（請別說4.0有事務，那個事務充其量算是對某些場合的數據操作的有益補充，不能和傳統數據庫做比較）

所以今天我們談了幾個問題

1  數據的插入與生成的主鍵的方式有關

2  數據插入速度，和INSERT 語句的寫法有關

3  數據的插入和附加信息有關（INDEX，外鍵，每行的附加信息，PAGE頁面的設計存儲方式）有關（這點本次么有提到）

4   數據的插入和數據的插入行中的某些附加的函數運算或者一些附加信息有關（本次沒有提到）

5    數據的插入方式，與數據庫LOG的關系（本次沒有提到）

凡是，沒有提到的問題，會在找一期來說說

結尾，一個高頻插入的系統，在每種數據庫的插入設計的時候，對HOT表都要有嚴格的要求，從表的設計，主鍵的設計，表插入行的方式設計，索引的設計，都要有考量，如果 在高頻系統中出現 insert into  select  這樣的語句，大方向我是不對其看好的。因為插入的時候，有的數據庫系統是會對表的插入也要加鎖 類似 next-key lock 這樣的鎖。

關于Insert的性能為啥這么差問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。