mysql 數據庫是社會普遍認可的非常流行的數據庫中間件之一，一套業務系統，數據庫的維護也是至關重要的。
應某位網友的要求，我將MySQL 5.7出現故障的恢復的過程記錄一下。
問題出現：
2020-05-19T11:48:11.883641Z 0 [ERROR] InnoDB: SYS_FIELDS.INDEX_ID mismatch
11:48:11 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68195 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x32e60d0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7ffd56a46910 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xf0702b]
/usr/sbin/mysqld(handle_fatal_signal+0x461)[0x7b93a1]
/lib64/libpthread.so.0(+0xf5f0)[0x7fdcb11535f0]
/lib64/libc.so.6(+0x13ed5a)[0x7fdcafc44d5a]
/usr/sbin/mysqld(_Z30dict_index_add_to_cache_w_vcolP12dict_table_tP12dict_index_tPK16dict_add_v_col_tmm+0x154)[0x1169014]
/usr/sbin/mysqld[0x117708b]
/usr/sbin/mysqld[0x117ae80]
/usr/sbin/mysqld(_Z15dict_load_tablePKcb17dict_err_ignore_t+0x568)[0x1172a28]
/usr/sbin/mysqld(_Z23dict_table_open_on_namePKcmm17dict_err_ignore_t+0x138)[0x1164598]
/usr/sbin/mysqld(_ZN11ha_innobase15open_dict_tableEPKcS1_b17dict_err_ignore_t+0x39)[0xf3ab39]
/usr/sbin/mysqld(_ZN11ha_innobase4openEPKcij+0x9ff)[0xf505ef]
/usr/sbin/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x33)[0x8075f3]
/usr/sbin/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0x8c7)[0xd6cac7]
/usr/sbin/mysqld(_Z10open_tableP3THDP10TABLE_LISTP18Open_table_context+0xe8b)[0xc7714b]
/usr/sbin/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjjP19Prelocking_strategy+0x612)[0xc7e102]
/usr/sbin/mysqld(_Z33open_trans_system_tables_for_readP3THDP10TABLE_LIST+0x50)[0xc7edf0]
/usr/sbin/mysqld(_Z10my_tz_initP3THDPKcc+0x6a8)[0xd811c8]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x1b26)[0x7b47e6]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fdcafb28505]
/usr/sbin/mysqld[0x7a91d4]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 0
Status: NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
以上是部分報錯日誌信息
根據日誌信息可以看出是系統表損壞了，而且還給出了參考手冊頁的地址：http://dev.mysql.com/doc/mysql/en/crashing.html
然後根據參考手冊頁看了半天，也沒找到具體如何解決和修復，於是繼續排查問題。
經過查詢和了解，發現mysql版本是5.7.24，操作系統是centos 7，截止目前mysql5.7最新版已經是5.7.30，於是升級了mysql相關的軟件包，將原來的配置文件進行了備份，安裝方式是使用yum在線安裝的，所有的配置都是默認，這裏由於是生產環境在使用的，不能直接將MySQL所有的刪除重新安裝，所以只能尋找恢復修復的辦法，如果是測試環境，數據不重要的，我這裏給出的解決辦法是直接將mysql的軟件包全部卸載，刪除配置文件，數據文件等相關文件，直接重新安裝，這種方式是最簡單最快捷的。
既然是數據庫的系統表損壞了，那麼我們順着這個思路，能不能我們把系統數據庫的表給複製一份呢，於是說幹就幹，就從其他地方複製了一份mysql數據庫的系統表到數據庫目錄下，結果發現仍然不能正常使用，mysqld服務根本就起不來。
到這裏就感覺很頭大了，網上也搜不到資料，而且各個類型的報錯信息都有所不同，別人使用的方式方法，經過驗證不適用，無法解決遇到的的問題。
那麼，既然多次嘗試，在原有的數據庫基礎上修復不了，那麼我們就自己重新安裝一個全新的數據庫，然後將原來的業務數據庫數據拷貝到新的數據庫裏面。跟着這個思路，我們還是使用yum來安裝mysql 5.7.30，安裝完成後，由於是默認的配置，而在默認的位置已經有了原有的數據，數據庫並沒有執行初始化，可以查看到日誌顯示初始化失敗，這裏我就不截圖了。
於是修改數據庫配置文件/etc/my.cnf，這裏安裝之前一定要把原有的數據庫配置文件和數據目錄進行備份，以免誤操作，造成原有的數據丟失，數據恢復是個比較費時費力的事情，切記，切記！！！
主要修改的內容有：
數據保存目錄 ：datadir=/opt/mysql
錯誤日誌文件：log-error=/opt/log/mysqld.log
套接字文件：socket=/opt/mysql/mysql.sock
進程文件：pidfile=/opt/mysqld.pid
然後創建相關文件目錄：
mkdir -p /opt/mysql
mkdir -p /opt/log
touch /opt/log/mysqld.log
touch /opt/mysql/mysql.sock
touch /opt/mysqld.pid
接着，給文件目錄授權，如果文件目錄權限不對，同樣會造成mysql服務起不來：
chown -R mysql.mysql /opt/mysql
chown -R mysql.mysql /opt/log
chown mysql.mysql /opt/mysqld.pid
chmod -R 755 /opt/mysql
chmod -R 755 /opt/log
######################################################################
啓動服務：systemctl start mysqld 沒有報錯就應該能啓動起來
查看狀態：systemctl status mysqld 正常的是綠色 顯示running
查看密碼：grep 'password' /opt/log/mysqld.log
登陸mysql:
mysql -uroot -p
發現使用剛纔從日誌裏面的查看的密碼並不能使用，報了一個錯誤，找不到套接字/var/lib/mysql/mysql.sock
這是因爲mysql客戶端默認使用的套接字是/var/lib/mysql/mysql.sock
於是我們在登陸的時候加上參數 -S /opt/mysql/mysql.sock 來指定我們自定義的套接字文件
或者我們建立軟鏈接，將我們自定義的套接字文件指向默認位置，
rm -rf /var/lib/mysql/mysql.sock
ln -s /opt/mysql/mysql.sock /var/lib/mysql/mysql.sock
然後再用日誌裏面查看的初始密碼來登陸就可以成功！！！ 這裏是需要注意的地方。
（其實也可以在配置文件中無需修改套接字文件位置，保持默認）
登陸成功後，就可以修改密碼：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass123_';
這裏因爲默認是開啓了密碼驗證，所以要設置了符合驗證規則的密碼
validate_password=off 配置文件中加入這句即可關閉密碼驗證
修改密碼後，配置允許使用root遠程連接：
grant all privileges on *.* to 'root'@'%' identified by 'MyNewPass123_' with grant option;
flush privileges;
接下來，將業務系統的數據目錄直接拷貝到新的數據目錄下：
cp -a -r /var/lib/mysql/xxx /opt/mysql/
登陸數據庫，查看數據庫和表：
mysql -uroot -p
show databases;
use xxx;
show tables;
最後驗證效果，發現有部分數據丟失，但是大部分數據都沒影響，可以正常使用。
以上內容，僅做個人記錄，僅供參考使用，如有錯漏之處，歡迎大家批評指正！！！
總結：
數據庫是業務系統中非常重要的東西，一旦發生故障將影響業務系統的正常運行，造成損失，建議使用多臺數據庫做集羣，並定期做備份，這樣可以避免單節點故障和數據庫宕機等引起的數據丟失。