資料庫服務啟動不了
『壹』 mysql 服務無法啟動是什麼原因
打開mysql server instance config ，然後，單擊next，然後選擇remove server instance，刪除後，然後卸載mysql程序，卸載完成後。打開 Documents and SettingsAll Users目錄，在裡面有個application data文件夾，如果沒有的話，那是他隱藏了，（工具----文件夾選項----顯示隱藏的文件），打開application data 文件夾，裡面有個mysql文件夾，刪除即可，然後重新安裝，絕對成功。
『貳』 SQL資料庫無法啟動
故障處理
移除當前使用的 redo log 文件，然後可以試著啟動資料庫，結果啟動失敗！
提示：
[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.
這樣的錯誤，這是因為 MySQL writer 線程按照配置的時間間隔以 page 為單位刷新 buffer 數據到磁碟。當數據刷新到磁碟的時候，新寫入磁碟的 page 包含了較新的 LSN，此時系統 system 表空間頭的 LSN 並沒有同步更新，通常這是檢查點線程的工作。在正常的崩潰恢復中，MySQL 可以藉助 redo log 來進行前滾和回滾，但是此時 redo log 已經被我們刪掉了，MySQL 無法進行恢復操作。此時，我們設置 innodb_force_recovery=3 來強制啟動 MySQL，仍然啟動不成功，改成 4 後啟動了！
再使用 mysqlmp 導出備份，結果噩夢又降臨了！MySQL 又 crash 了。
提示：
InnDB: Failed to find tablespace for table......
設置參數 innodb_force_recovery=5，資料庫仍然啟動失敗，再設置成 6，啟動成功！用 sqlmp 順利把數據備份出來了！
再初始化資料庫，把剛剛備份的資料庫導入，資料庫恢復成功完成！
參數說明
這里的關鍵是設置 innodb_force_recovery 參數，對應這個參數的說明如下：
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：不執行前滾的操作。
『叄』 mysql 服務無法啟動
這個問題出現在MySQL5.7之後的版本，主要的原因是MySQL會在最新的check point完成後都會在redolog寫一個一位元組的MLOG_CHECKPOINT標記，用來標記在此之前的redo都已checkpoint完成。
如果處於任何原因沒有找到這個標記，那麼整個redolog文件都會被忽略。出現這個錯誤的話，最好是有備份進行恢復，如果沒有做好備份，那隻能採取非常規的啟動方式，但可能造成數據丟失。
介紹
MySQL是一個關系型資料庫管理系統，由瑞典MySQLAB公司開發，屬於Oracle旗下產品。MySQL是最流行的關系型資料庫管理系統之一，在WEB應用方面，MySQL是最好的RDBMS應用軟體之一。
MySQL是一種關系型資料庫管理系統，關系資料庫將數據保存在不同的表中，而不是將所有數據放在一個大倉庫內，這樣就增加了速度並提高了靈活性。
『肆』 mysql啟動不了資料庫服務
windows下：
1.
打開命令行窗口（cmd），如果安裝的mysql服務名為mysql，則net
start
mysql(此步也可直接在控制面板->管理->服務中啟動mysql)
2.
輸入命令進入到mysql的安裝目錄中的bin目錄內，如安裝目錄為c:\program
files\mysql，則輸入命令cd
c:\program
files\mysql\bin；
3.
使用命令啟動mysql服務，如用戶名為root密碼為123456，則命令mysql
-u
root
-p
123456；如果登錄成功，則說明mysql服務啟動成功。
linux下：
1.
直接在命令行窗口中service
mysql
start(假設服務名稱為mysql);
2.
然後按windows下的第2和第3步進行同樣驗證；
『伍』 mysql啟動不了服務啟動不了該怎麼辦
一、無法訪問系統資源
MySQL 不能訪問啟動需要的資源是造成而 MySQL 無法啟動的一個常見原因，如：文件，埠等。由於 linux 中用於啟動 mysqld 進程的 mysql 用戶通常是不能登陸的，可以使用類似下面的命令檢查文件的訪問許可權。
sudo -u mysql touch /var/lib/mysql/b
找出問題後，修改對應文件或目錄的許可權或屬主後通常可以解決問題。但有時 mysql 用戶有訪問文件和目錄的許可權，但仍然會被拒絕訪問，例如下面這個例子：
mysql> system sudo -u mysql touch /home/mysql/data/a
mysql> create table t1 (
id int primary key,n varchar(10
) data directory
ERROR 1030 (HY000): Got error 168 from storage engine
測試說明 mysql 用戶有這個目錄的訪問許可權，但創建文件還是失敗，這種情況讓很多人困惑，這個時候通常是 mysqld 進程的訪問被 linux 的 selinux 或 apparmor 給阻止了，大家可以看到創建的表不是在 mysql 的默認目錄下面，因此 selinux 或 apparmor 的 policy 裡面沒有包含這個目錄的訪問許可權，此時只要對應的修改 policy 就行了，當然把 selinux 或 apparmor 停了也行。
有時雖然對系統資源有訪問的許可權，但系統資源已經被佔用：
mysqld --no-defaults --console --user mysql
2020-11-03T03:36:07.519419Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19) starting as process 21171
2020-11-03T03:36:07.740347Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11
這個故障產生的原因是另外一個 mysqld 進程已經啟動並佔用了對應的文件。
二、參數設置錯誤
參數設置錯誤造成 MySQL 無法啟動的原因也非常常見，此時先要檢查 MySQL 啟動時會調用的參數，下面的命令可以查詢 MySQL 啟動時調用參數文件的順序：
$ mysqld --verbose --help | grep "Default options " -A 1
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
知道了 MySQL 參數文件的調用順序，我們就可以檢查對應的參數文件，找出其中的錯誤，如果覺得參數文件的可讀性不強，可以使用下面的命令顯示 mysqld 程序將要調用的參數：
$ mysqld --print-defaults
/usr/sbin/mysqld would have been started with the following arguments:
......
注意這個命令顯示完參數後就退出，不會真正運行 mysqld。這個命令和 my_print_defaults mysqld 完全是等價的，只不過後者的顯示方式是一行一個參數。
然後開始對可疑的參數進行調試，我個人喜歡加的參數和順序如下：
1. 在 mysqld 後加上第一個參數 --no-defaults ，這個參數的作用是通知 mysqld 在啟動的時候不要讀任何參數文件；
2. 第二個參數是 --console，這個參數會把錯誤信息輸出到屏幕上，這個參數帶來的一個弊端是所有的信息都輸出到屏幕上，讓屏幕顯得比較亂，但對於我們調試卻是很方便的；
3. 第三個參數是 --log-error-verbosity=3，這個參數會顯示詳細的日誌；
4. 然後再在後面加上有把握的參數，可以一次只加一個參數，然後啟動 mysqld，採用排除法逐步找出錯誤的參數。