mysql數據庫崩潰的原因(mysql崩潰恢復)

當MySQL從崩潰中恢復時，它將遍歷所有ibd文件的headerpage，以驗證數據字典的準確性。如果MySQL包含大量的表，這個驗證過程將會非常耗時。MySQL下的崩潰恢復確實和表的數量有關。表的總數越多，崩潰恢復時間就越長。此外，磁盤IOPS也會影響崩潰恢復時間。比如這裏開發庫的HDDIOPS低，所以面對大量的表空間驗證速度很慢。還有壹個發現是，MySQL8正常啟用的時候，實際上會檢查表空間，而恢復的時候會再次檢查表空間，相當於檢查了兩次。不過MySQL8.0有壹個額外的特性，就是當表數超過5W時，會啟用多線程掃描來加快表空間驗證過程。

如何跳過驗證在MySQL5.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變量，妳的想法就破滅了。