當前位置:成語大全網 - 書法字典 - mysql數據庫突然變慢的原因是什麽?

mysql數據庫突然變慢的原因是什麽?

當MySQL從崩潰中恢復時,它將遍歷所有ibd文件的頭頁,以驗證數據字典的準確性。如果MySQL包含大量的表,這個驗證過程將會非常耗時。MySQL下的崩潰恢復確實和表的數量有關。表的總數越多,崩潰恢復時間就越長。此外,磁盤IOPS也會影響崩潰恢復時間。比如這裏的開發庫的HDD IOPS低,所以面對大量的表空間驗證速度非常慢。另壹個發現是,MySQL 8正常啟用時,實際上會檢查表空間,而恢復時會再次檢查表空間,相當於檢查了兩次。不過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文件,大大節省了驗證時間。聽了姜老師關於用* * *共享表空間代替獨立表空間解決掉大表時性能抖動的理論,感覺* * *共享表空間在很多業務環境下更有優勢。

另壹個解決方案臨時冒出來了,就是用GDB調試崩潰恢復,通過臨時修改validate變量的值,讓MySQL跳過表空間驗證過程,然後正常關閉MySQL,正常重啟。但實際測試表明,如果在調試模式下運行,確實可以臨時修改validate變量,跳過表空間驗證過程,但調試模式下代碼運行效率大大降低,但耗時更長。但是,如果在非調試模式下運行,就不能修改validate變量,妳的想法就破滅了。