Insert的性能為啥這么差

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

最近發(fā)現(xiàn)單位某些系統(tǒng)的的插入性能不是很好，誠然知道物理存儲(chǔ)的性能不是很好，在關(guān)鍵系統(tǒng)都在使用SSD 的時(shí)代，我們還沒有進(jìn)入SSD的懷抱。但另一個(gè)點(diǎn)，為什么有的地方使用費(fèi)SSD 的設(shè)備，其實(shí)插入的性能還好，或者說如果換裝SSD 設(shè)備后，其實(shí)也看不出區(qū)別。 排除數(shù)據(jù)量小的問題，其實(shí)數(shù)據(jù)庫對(duì)插入的優(yōu)化也是需要的。

那么我們分析一下，插入其中會(huì)遇到哪些問題，這里我們可能不會(huì)限定某種數(shù)據(jù)庫，而是大范圍的討論，當(dāng)然有些問題可能是針對(duì)某些數(shù)據(jù)庫，這邊會(huì)有所體現(xiàn)。

1 問題， 我們是使用自增的方式 還是使用散列的方式進(jìn)行數(shù)據(jù)的插入

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

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

那到底是不是這樣，我們來進(jìn)行分析，如果是自增的方式，在大量數(shù)據(jù)插入的時(shí)候，會(huì)出現(xiàn)熱點(diǎn)問題，我們現(xiàn)已MYSQL 為例

線程 1 

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

線程2

insert into table select .... from table 2

我們來看一下上面的語句，如果同時(shí)運(yùn)行，而且我們還是用了MYSQL的 自增方式會(huì)出現(xiàn)什么問題。

對(duì)，自增主鍵的熱點(diǎn)，這也就是MYSQL 在5.5之前在大量數(shù)據(jù)插入的時(shí)候，被詬病的問題。那后來MYSQL 是怎么解決的，這里就要說到MYSQL的 自增的 三個(gè)參數(shù)，我們現(xiàn)在大部分選擇

innodb_autoinc_lock_mode = 2

這樣的選擇，有什么問題？顯而易見，ID 在大量的插入的時(shí)候，可能出現(xiàn)不連續(xù)的問題。 

我們通過上面的語句可以看到什么，一個(gè)插入的語句要使用 using where using temporary, 為什么？  大家可以思考一下這個(gè)問題，并且想想如果這個(gè)select后面的語句是大量的數(shù)據(jù)，對(duì)一個(gè)高頻詞運(yùn)行效率優(yōu)先的系統(tǒng)，是不是一件好事情。文章結(jié)尾會(huì)有一個(gè)簡(jiǎn)單的說明。

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

MONGODB 中的主鍵主要是由幾個(gè)方面產(chǎn)生的，unix 時(shí)間，MONGODB的機(jī)器碼標(biāo)識(shí)，一個(gè)隨機(jī)數(shù)，等等生成的，這里便宜一個(gè)話題，如果想使用雪花算法，可以考慮借鑒一下 MONGODB 的OBJECT_ID的生成方法，當(dāng)然MONGODB的 OBJECT_ID 考慮了很多，所以對(duì)數(shù)以億萬的數(shù)據(jù)也不會(huì)有撞庫的風(fēng)險(xiǎn)。

以下就是MONGODB 的數(shù)據(jù)存儲(chǔ)的方式，這點(diǎn)方式和 HEAP 表的存儲(chǔ)方式類似，當(dāng)然由于非事務(wù)性性（請(qǐng)別說4.0有事務(wù)，那個(gè)事務(wù)充其量算是對(duì)某些場(chǎng)合的數(shù)據(jù)操作的有益補(bǔ)充，不能和傳統(tǒng)數(shù)據(jù)庫做比較）

所以今天我們談了幾個(gè)問題

1  數(shù)據(jù)的插入與生成的主鍵的方式有關(guān)

2  數(shù)據(jù)插入速度，和INSERT 語句的寫法有關(guān)

3  數(shù)據(jù)的插入和附加信息有關(guān)（INDEX，外鍵，每行的附加信息，PAGE頁面的設(shè)計(jì)存儲(chǔ)方式）有關(guān)（這點(diǎn)本次么有提到）

4   數(shù)據(jù)的插入和數(shù)據(jù)的插入行中的某些附加的函數(shù)運(yùn)算或者一些附加信息有關(guān)（本次沒有提到）

5    數(shù)據(jù)的插入方式，與數(shù)據(jù)庫LOG的關(guān)系（本次沒有提到）

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

結(jié)尾，一個(gè)高頻插入的系統(tǒng)，在每種數(shù)據(jù)庫的插入設(shè)計(jì)的時(shí)候，對(duì)HOT表都要有嚴(yán)格的要求，從表的設(shè)計(jì)，主鍵的設(shè)計(jì)，表插入行的方式設(shè)計(jì)，索引的設(shè)計(jì)，都要有考量，如果 在高頻系統(tǒng)中出現(xiàn) insert into  select  這樣的語句，大方向我是不對(duì)其看好的。因?yàn)椴迦氲臅r(shí)候，有的數(shù)據(jù)庫系統(tǒng)是會(huì)對(duì)表的插入也要加鎖 類似 next-key lock 這樣的鎖。

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