数据库服务启动不了
‘壹’ 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，采用排除法逐步找出错误的参数。