1、崩潰恢複相關參數解析：
innodb_fast_shutdown: innodb_fast_shutdown = 0：這個表示在MySQL關閉的時候，執行slow shutdown，不但包括日志的刷盤，資料頁的刷盤，還包括資料的清理(purge)，ibuf的合并，buffer pool dump以及lazy table drop操作(如果表上有未完成的操作，即使執行了drop table且傳回成功了，表也不一定立刻被删除)。 innodb_fast_shutdown = 1：這個是預設值，表示在MySQL關閉的時候，僅僅把日志和資料刷盤。 innodb_fast_shutdown = 2：這個表示關閉的時候，僅僅日志刷盤，其他什麼都不做，就好像MySQL crash了一樣。 這個參數值越大，MySQL關閉的速度越快，但是啟動速度越慢，相當于把關閉時候需要做的工作挪到了崩潰恢複上。另外，如果MySQL要更新，建議使用第一種方式進行一次幹淨的shutdown。
innodb_force_recovery: 這個參數主要用來控制InnoDB啟動時候做哪些工作，數值越大，做的工作越少，啟動也更加容易，但是資料不一緻的風險也越大。當MySQL因為某些不可控的原因不能啟動時，可以設定這個參數，從1開始逐漸遞增，知道MySQL啟動，然後使用SELECT INTO OUTFILE把資料導出，盡最大的努力減少資料丢失。 innodb_force_recovery = 0：這個是預設的參數，啟動的時候會做所有的事情，包括redo日志應用，undo日志復原，啟動背景master和purge線程，ibuf合并。檢測到了資料頁損壞了，如果是系統表空間的，則會crash，使用者表空間的，則打錯誤日志。 innodb_force_recovery = 1：如果檢測到資料頁損壞了，不會crash也不會報錯(buf_page_io_complete)，啟動的時候也不會校驗表空間第一個資料頁的正确性(fil_check_first_page)，表空間無法通路也繼續做崩潰恢複(fil_open_single_table_tablespace、fil_load_single_table_tablespace)，ddl操作不能進行(check_if_supported_inplace_alter)，同時資料庫也被不能進行寫入操作(row_insert_for_mysql、row_update_for_mysql等)，所有的prepare事務也會被復原(trx_resurrect_insert、trx_resurrect_update_in_prepared_state)。這個選項還是很常用的，資料頁可能是因為磁盤壞了而損壞了，設定為1，能保證資料庫正常啟動。 innodb_force_recovery = 2：除了設定1之後的操作不會運作，背景的master和purge線程就不會啟動了(srv_master_thread、srv_purge_coordinator_thread等)，當你發現資料庫因為這兩個線程的原因而無法啟動時，可以設定。 innodb_force_recovery = 3：除了設定2之後的操作不會運作，undo復原資料庫也不會進行，但是復原段依然會被掃描，undo連結清單也依然會被建立(trx_sys_init_at_db_start)。srv_read_only_mode會被打開。 innodb_force_recovery = 4：除了設定3之後的操作不會運作，ibuf的操作也不會運作(ibuf_merge_or_delete_for_page)，表資訊統計的線程也不會運作(因為一個壞的索引頁會導緻資料庫崩潰)(info_low、dict_stats_update等)。從這個選項開始，之後的所有選項，都會損壞資料，慎重使用。 innodb_force_recovery = 5：除了設定4之後的操作不會運作，復原段也不會被掃描(recv_recovery_rollback_active)，undo連結清單也不會被建立，這個主要用在undo日志被寫壞的情況下。 innodb_force_recovery = 6：除了設定5之後的操作不會運作，資料庫前滾操作也不會進行，包括解析和應用(recv_recovery_from_checkpoint_start_func)。
2、事務送出相關參數解析：
innodb_flush_log_at_trx_commit：這個參數控制InnoDB 存儲引擎事務送出時的redo重新整理機制。innodb_flush_log_at_trx_commit = 0：Innodb 中的Log Thread 沒隔1 秒鐘會将logbuffer中的資料寫入到檔案，同時還會通知檔案系統進行檔案同步的flush操作，保證資料确實已經寫入到磁盤上面的實體檔案。但是，每次事務的結束（commit 或者是rollback）并不會觸發LogThread 将log buffer 中的資料寫入檔案。是以，當設定為0 的時候，當MySQL Crash 和OS Crash或者主機斷電之後，最極端的情況是丢失1 秒時間的資料變更。innodb_flush_log_at_trx_commit = 1：這也是Innodb的預設設定。我們每次事務的結束都會觸發Log Thread 将log buffer中的資料寫入檔案并通知檔案系統同步檔案。這個設定是最安全的設定，能夠保證不論是MySQL Crash 還是OS Crash或者是主機斷電都不會丢失任何已經送出的資料。innodb_flush_log_at_trx_commit = 2：當我們設定為2 的時候，Log Thread會在我們每次事務結束的時候将資料寫入事務日志，但是這裡的寫入僅僅是調用了檔案系統的檔案寫入操作。而我們的檔案系統都是有緩存機制的，是以LogThread的這個寫入并不能保證内容真的已經寫入到實體磁盤上面完成持久化的動作。檔案系統什麼時候會将緩存中的這個資料同步到實體磁盤檔案LogThread 就完全不知道了。是以，當設定為2 的時候，MySQL Crash 并不會造成資料的丢失，但是OS Crash或者是主機斷電後可能丢失的資料量就完全控制在檔案系統上了。
binlog_sync:這個參數控制mysql server 事務送出時二進制日志的同步機制。binlog_sync=0:事務送出時，mysql server 不主動同步binlog 到磁盤，由OS 檔案系統決定何時同步，當mysql server 或者OS crash時存在binlog 丢失風險。binlog_sync=1:事務每次送出時，mysql server 都将binlog 同步至磁盤，安全性最高，IO 壓力最大，mysql 可以通過group commit 機制來改善IO壓力。binlog_sync=n(n>1)：每進行n次事務送出時，mysql server 将binlog 同步至磁盤，當mysql server 或者OS crash 時存在binlog 丢失風險。