問題描述
1 mysql數據庫5.6無法正常啟動
2 直接復制替換innodb的frm和idb文件來新增數據表導致的問題
3 innodb文件ibdata1，ib_logfile0，ib_logfile1損壞，數據不一致
4 沒有sql備份，無法正常登陸和導出當天數據
注意事項
innodb的表不能直接復制替換frm和idb文件，而是使用工具正常導入導出，myisam表可以直接復制替換文件
解決方法
1 開啟mysql錯誤日志，觀察日志來判斷數據庫什么問題（此次問題比較清楚，innodb損壞，ibdata1損壞導致）
2 innodb_force_recovery （0-6級別） 此次使用6強制啟動
1(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁。
2(SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程需要執行full purge操作，會導致crash。
3(SRV_FORCE_NO_TRX_UNDO):不執行事務回滾操作。
4(SRV_FORCE_NO_IBUF_MERGE):不執行插入緩沖的合並操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存儲引擎會將未提交的事務視為已提交。
6(SRV_FORCE_NO_LOG_REDO):不執行前滾的操作。
當設置innodb_force_recovery大於0后，可以對標進行select、create、drop操作，但insert、update或者delete這類操作是不允許的
3 innodb_force_recovery=6 正常啟動mysql后，無法使用navicat工具導出數據量大的的數據庫，正常工具導出還會導致數據庫崩潰（此處沒有最近的sql備份，只有損壞后數據庫目錄直接備份，但是ibdata1損壞，所以這個備份沒有意義，所以此處還是要導出正常的sql備份，用來恢復當天最近的數據）
4 嘗試使用innochecksum -f ibdata1工具來修復ibdata損壞,但是沒有效果
5 使用mysqldump命令進行導出（此處遇到問題，和原來業務的數據編碼問題，重新創建mysql環境，數據庫創建問題，表創建問題，索引創建問題）
1 數據編碼問題，此處並不是普通的中文亂碼問題，而是編碼: JUSTEP154053; 提示: KSQL語法錯誤，源程序服務tomcat啟動問題
這個編碼問題分為兩步 ：tomcat啟動報錯，數據庫和表的編碼問題，tomcat正常啟動后里的程序頁面報錯，這是數據的編碼問題
2 此處遇到數據庫，表創建，數據問題，手動創建新的utf-8，但是不生效，雖然都和原環境一直，但還是會出現編碼報錯，業務有問題
3 解決無論導入和導出都需要加上--default-character-set=utf8（防止編碼: JUSTEP154053，防止mysql錯誤導入ERROR 1064 (42000)）
4 此次為了快速解決，使用了原來2018-04月的備份數據庫，使用原來數據庫的庫和表結構，清空數據
5 導出來加-t 只導出數據，不導出表結構
6 解決步驟
1 導出三個庫所需的數據 --default-character-set=utf8 只導出數據，不導結構
2 確保導出備份數據可以使用后，刪除原有數據庫文件
3 備份MySQL數據目錄下的ib_logfile0、ib_logfile1、ibdata1三個文件，然后將這三個文件刪除
4 innodb_force_recovery = 0 重新啟動mysql 重建 ib_logfile0、ib_logfile1、ibdata1 此時所有數據表都無法打開
5 重新導入數據文件 --default-character-set=utf8 導入數據
mysql數據恢復通過frm和idb文件（此處沒有使用）
記錄參考https://blog.csdn.net/Sonny_alice/article/details/80198200
整個恢復過程其實可以總結為下面幾步：
一：無表數據結構
(1)：恢復表結構
(2)：復制出來創建表的sql語句
(3)：恢復表數據(在恢復表數據的時候，首先需要解除當前創建的表與默認生成的.ibd文件間的關系，接着將要恢復數據表的.ibd文件與當前創建的表聯系起來即可)
(4)：alter table songlyric discard tablespace;alter table songlyric import tablespace;