怎樣對比mysqlpump和mysqldump的性能

本篇文章給大家分享的是有關怎樣對比mysqlpump和mysqldump的性能，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

昨天測試了一下mysqlpump，今天來把剩下的補充完成，算是一個小的系列。

mysqlpump

在MySQL 5.7中做邏輯備份恢復有了一個新的工具mysqlpump，如果你掌握了mysqldump,那么使用mysqlpump就是分分鐘的事情，因為很多參數都是很相似的，可以理解它是mysqldump的加強版，一個亮點就是有了并行的選項，使得數據備份的性能更加強大。

  有一點值得說明的是，為了保證數據一致性，我們一般備份都會使用--single-transaction的選項，在5.7.11以前，mysqlpump和并行參數是有沖突的，在這個版本之后做了修復。

  但是mysqlpump到底怎么樣呢，我在5.7.17的版本中做了一些簡單的測試，可以看出一些性能的差異。

  而mysqldump是大家最耳熟能詳的工具了，如果沒用過，都不好意思說自己會MySQL,這樣一個工具和Oracle里的exp工具一般，經典而且功能豐富。  

測試環境說明

   為了盡可能保證導出的數據備份能夠占用少的磁盤空間，我們經常會使用gzip來壓縮，我們就分了幾個場景來對比壓縮，不壓縮，開啟并行后的數據備份的性能差異。

   我選取的數據集大小在30G左右。含有5個數據庫，單表數據量在200萬以上，單庫的表數量在10個以上。

數據備份的測試結果

數據備份的測試場景自己做得多一些，當然備份層面的壓縮暫時還沒有測完整，其它的場景

可以看到默認來說，導出一個30G左右的dump需要近7分鐘，而啟用了并行之后，并行度為4的時候，導出時間是5分半，提升了1.5分鐘（20%），并行度為8之后提升了2分鐘左右（30%）。而在系統層面做了壓縮的時候，壓縮率達到了近48%，而并行度在更大的時候，備份速度就差別不大了，一來也和CPU的情況有關，整體來說并行的效果還是不錯的。在compress=true只是在服務端客戶端交互中使用數據包壓縮，最后的備份集大小是沒有任何改變的。后續會測試使用不同的壓縮算法，備份的性能差異。

系統層面壓縮備份的情況

如果備份不通過gzip管道來壓縮，而是直接生成備份壓縮，效率如果呢。一個26G左右的備份，gzip壓縮的時間大概是43m18.974s，其實還真不短，比預想的長多了。

數據導入效率

數據的導入，我就簡單測試了兩個場景，mysqlpump并行備份導出，導入，mysqldump備份導出導入

以上就是怎樣對比mysqlpump和mysqldump的性能，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。