數據字典線程

當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文件，這大大節省了驗證時間。聽了蔣老師用* * *共享表空間代替獨立表空間解決大表drop時性能抖動的理論後，感覺* * *共享表空間在很多業務環境中更有優勢。

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