mysql數據庫還原慢（sqlserver數據庫寫入慢）

本文目錄一覽：

• 1、MySQL數據庫服務器逐漸變慢 該如何分析與解決
• 2、如何有效地提高 MySQL 的備份和恢復速度
• 3、求助，用 Navicat 還原 Mysql 數據庫奇慢

MySQL數據庫服務器逐漸變慢 該如何分析與解決

MySQL 在崩潰恢復時，會遍歷打開所有 ibd 文件的 header page 驗證數據字典的準確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關，表總數越大，崩潰恢復時間越長。另外磁盤 IOPS 也會影響崩潰恢復時間，像這裡開發庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發現，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復時則會額外再進行一次表空間校驗，等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。

如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那麼 validate = false，即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1，也就是強制恢復跳過壞頁，就可以跳過校驗，然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發現有什麼隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後，感覺共享表空間在很多業務環境下，反而更有優勢。

臨時冒出另外一種解決想法，即用 GDB 調試崩潰恢復，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然後讓 MySQL 正常關閉，重新啟動就可以正常啟動了。但是實際測試發現，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。

如何有效地提高 MySQL 的備份和恢復速度

一 加速備份

1、 加了single-transaction參數 備份時 需要先flush table with read lock 這個過程中會有一個鎖表的過程，如果有事務或語句正在執行，沒有結束，那麼備份進程會一直等待，並且阻塞別的事務，那麼也會影響業務。所以要先確認備份的時候沒有大的事務在運行。具體 single-transaction的加鎖可以參考 我的博客：mysqldump備份時加single-transaction會不會加鎖

2 、mysqldump是單進程的，沒有辦法並行，但現在機器的瓶頸多是出現在IO方面，可以使用更了的IO設備加快速度

3 、mysqldump時如果空間夠的話，不要邊壓縮邊備份

二 加速恢復

1 關閉binlog:不寫入Binlog會大大的加快數據導入的速度

2 innodb_flush_log_at_trx_commit=0

3 更好的配置

建議：

如果非要使用邏輯備份，可以考慮mysqldumper, mysqlpump(5.7)這兩個工具去備份，這兩個在備份的時候支持並行操作，mysqldumper還可以對單表進行恢復，在只需要恢復單表的情況下，恢復速度會大大加快

使用物理備份 xtrabackup (open source),MEB(oracle提供，收費)： 他們的備份原理是基於mysql crash recover， 備份速度 是和邏輯備份的相差不太大。但是恢復速度卻有很大的提升。

邏輯備份 備出來的是sql語句文件，恢復時需要一條一條的執行sql,所以恢復很慢。

而物理備份和還原的速度 相當於直接copy文件，所以恢復的時候性能有很大的提升

並且這兩個軟件還支持並行，效果更好。

邏輯備份最大的優點是 備份好的文件經壓縮後佔用空間較小，最大缺點恢復太慢

物理備份可以很快的恢復，但是備份好的文件壓縮後佔用空間比邏輯備份要大。

求助，用 Navicat 還原 Mysql 數據庫奇慢

二、打開Navicat—連接—Mysql 三、填寫數據庫連接信息 四、導出數據庫文件雙擊打開創建的連接—選擇您的數據庫—右鍵點擊—選擇”轉儲SQL文件”，即可將數據庫導入成.sql文件五、 導入數據庫文件 1）雙擊打開創建的連接—選擇您的數據庫—右鍵點擊—選擇”運行SQL文件”2）選擇您的數據庫備份文件以及備份文件的編碼，默認選擇的編碼為65001 (UTF-8)。如果導入失敗，可以刪除失敗的表，嘗試選擇936（ Simplified Chinese GBK ） 再次導入 3）如果進度條顯示完成，並且沒有提示錯誤，則成功導入。