MySQL 在崩潰恢復時，會遍歷打開所有 ibd 文件的 header page 驗證數(shù)據(jù)字典的準確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數(shù)量有關，表總數(shù)越大，崩潰恢復時間越長。另外磁盤 IOPS 也會影響崩潰恢復時間，像這里開發(fā)庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發(fā)現(xiàn)，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復時則會額外再進行一次表空間校驗，等于校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數(shù)量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。
網(wǎng)站建設哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、成都小程序開發(fā)、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了東坡免費建站歡迎大家使用！
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1，也就是強制恢復跳過壞頁，就可以跳過校驗，然后重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復后非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節(jié)省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理后，感覺共享表空間在很多業(yè)務環(huán)境下，反而更有優(yōu)勢。
臨時冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然后讓 MySQL 正常關閉，重新啟動就可以正常啟動了。但是實際測試發(fā)現(xiàn)，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。
安全地關閉MySQL實例
關閉過程：
1、發(fā)起shutdown，發(fā)出 SIGTERM信號
2、有必要的話，新建一個關閉線程(shutdown
thread)
如果是客戶端發(fā)起的關閉，則會新建一個專用的關閉線程
如果是直接收到 SIGTERM 信號進行關閉的話，專門負責信號處理的線程就會負責關閉工作，或者新建一個獨立的線程負責這個事
當無法創(chuàng)建獨立的關閉線程時（例如內(nèi)存不足），MySQL Server會發(fā)出類似下面的告警信息：
?
1Error: Can't create thread to kill server
3、MySQL Server不再響應新的連接請求
關閉TCP/IP網(wǎng)絡監(jiān)聽，關閉Unix Socket等渠道
4、逐漸關閉當前的連接、事務
空閑連接，將立刻被終止；
當前還有事務、SQL活動的連接，會將其標識為 killed，并定期檢查其狀態(tài)，以便下次檢查時將其關閉；（參考 KILL 語法）
當前有活躍事務的，該事物會被回滾，如果該事務中還修改了非事務表，則已經(jīng)修改的數(shù)據(jù)無法回滾，可能只會完成部分變更；
如果是Master/Slave復制場景里的Master，則對復制線程的處理過程和普通線程也是一樣的；
如果是Master/Slave復制場景里的Slave，則會依次關閉IO、SQL線程，如果這2個線程當前是活躍的，則也會加上 killed
標識，然后再關閉；
Slave服務器上，SQL線程是允許直接停止當前的SQL操作的（為了避免復制問題），然后再關閉該線程；
在MySQl
5.0.80及以前的版本里，如果SQL線程當時正好執(zhí)行一個事務到中間，該事務會回滾；從5.0.81開始，則會等待所有的操作結束，除非用戶發(fā)起KILL操作。
當Slave的SQL線程對非事務表執(zhí)行操作時被強制 KILL了，可能會導致Master、Slave數(shù)據(jù)不一致；
5、MySQL Server進程關閉所有線程，關閉所有存儲引擎；
刷新所有表cache，關閉所有打開的表；
每個存儲引擎各自負責相關的關閉操作，例如MyISAM會刷新所有等待寫入的操作；InnoDB會將buffer pool刷新到磁盤中（從MySQL
5.0.5開始，如果innodb_fast_shutdown不設置為 2 的話），把當前的LSN記錄到表空間中，然后關閉所有的內(nèi)部線程。
6、MySQL Server進程退出
關于KILL指令
從5.0開始，KILL 支持指定 CONNECTION | QUERY兩種可選項：
KILL CONNECTION和原來的一樣，停止回滾事務，關閉該線程連接，釋放相關資源；
KILL
QUERY則只停止線程當前提交執(zhí)行的操作，其他的保持不變；
提交KILL操作后，該線程上會設置一個特殊的
kill標記位。通常需要一段時間后才能真正關閉線程，因為kill標記位只在特定的情況下才檢查：
1、執(zhí)行SELECT查詢時，在ORDER BY或GROUP BY循環(huán)中，每次讀完一些行記錄塊后會檢查
kill標記位，如果發(fā)現(xiàn)存在，該語句會終止；
2、執(zhí)行ALTER TABLE時，在從原始表中每讀取一些行記錄塊后會檢查 kill
標記位，如果發(fā)現(xiàn)存在，該語句會終止，刪除臨時表；
3、執(zhí)行UPDATE和DELETE時，每讀取一些行記錄塊并且更新或刪除后會檢查 kill
標記位，如果發(fā)現(xiàn)存在，該語句會終止，回滾事務，若是在非事務表上的操作，則已發(fā)生變更的數(shù)據(jù)不會回滾；
4、GET_LOCK()
函數(shù)返回NULL；
5、INSERT
DELAY線程會迅速內(nèi)存中的新增記錄，然后終止；
6、如果當前線程持有表級鎖，則會釋放，并終止；
7、如果線程的寫操作調(diào)用在等待釋放磁盤空間，則會直接拋出逗磁盤空間滿地錯誤，然后終止；
8、當MyISAM表在執(zhí)行REPAIR
TABLE 或 OPTIMIZE TABLE 時被 KILL的話，會導致該表損壞不可用，指導再次修復完成。
安全關閉MySQL幾點建議
想要安全關閉 mysqld 服務進程，建議按照下面的步驟來進行：
0、用具有SUPER、ALL等最高權限的賬號連接MySQL，最好是用 unix socket
方式連接；
1、在5.0及以上版本，設置innodb_fast_shutdown = 1，允許快速關閉InnoDB（不進行full
purge、insert buffer
merge），如果是為了升級或者降級MySQL版本，則不要設置；
2、設置innodb_max_dirty_pages_pct =
0，讓InnoDB把所有臟頁都刷新到磁盤中去；
3、設置max_connections和max_user_connections為1，也就最后除了自己當前的連接外，不允許再有新的連接創(chuàng)建；
4、關閉所有不活躍的線程，也就是狀態(tài)為Sleep
且 Time 大于 1 的線程ID；
5、執(zhí)行 SHOW PROCESSLIST
確認是否還有活躍的線程，尤其是會產(chǎn)生表鎖的線程，例如有大數(shù)據(jù)集的SELECT，或者大范圍的UPDATE，或者執(zhí)行DDL，都是要特別謹慎的；
6、執(zhí)行
SHOW ENGINE INNODB STATUS 確認History list
length的值較低（一般要低于500），也就是未PURGE的事務很少，并且確認Log sequence number、Log flushed up
to、Last checkpoint at三個狀態(tài)的值一樣，也就是所有的LSN都已經(jīng)做過檢查點了；
7、然后執(zhí)行FLUSH LOCKAL TABLES
操作，刷新所有 table cache，關閉已打開的表（LOCAL的作用是該操作不記錄BINLOG）；
8、如果是SLAVE服務器，最好是先關閉
IO_THREAD，等待所有RELAY LOG都應用完后，再關閉 SQL_THREAD，避免 SQL_THREAD
在執(zhí)行大事務被終止，耐心待其全部應用完畢，如果非要強制關閉的話，最好也等待大事務結束后再關閉SQL_THREAD；
9、最后再執(zhí)行 mysqladmin
shutdown。
10、緊急情況下，可以設置innodb_fast_shutdown = 1，然后直接執(zhí)行 mysqladmin shutdown
即可，甚至直接在操作系統(tǒng)層調(diào)用 kill 或者 kill -9 殺掉 mysqld 進程（在innodb_flush_log_at_trx_commit = 0
的時候可能會丟失部分事務），不過mysqld進程再次啟動時，會進行CRASH RECOVERY工作，需要有所權衡。
auto_increment設置這個會自動增加了，這個增加時在現(xiàn)有的ID基礎上的，如果 你數(shù)據(jù)庫還是空記錄的話，最好添加一條完整記錄，然后在插入數(shù)據(jù)的時候，就可以不用設置ID
重慶分公司
重慶分公司
