数据库启动失败
一、mysqld 进程没有正常运行遇到这种情况首先到服务器上看看 mysqld 进程是否活着，采用的命令：
二、客户端不能和进程 mysqld 通信如果 MySQL 服务器上的 mysqld 进程运行正常，我们再看看客户端能不能和 mysqld 进行通信，使用下面的命令进行网络连通的测试：telnet localhost 3306
如果本地能通，再到客户端的机器上把 localhost 换成 MySQL 服务器的 ip 地址进行测试。如果不能通，通常有两种原因，一种原因是 OS 或网络的问题，或者是防火墙；另一种原因是 mysqld 自身根本没有侦听客户端的连接请求， mysqld 启动后对于客户端的侦听是分三种情况。
第一种情况
是使用参数 --skip-networking 跳过侦听客户端的网络连接，用下面的命令我们可以看到 MySQL 根本没有侦听 3306 端口。
第二种情况
使用参数 --bind-address 后面增加对客户端访问 IP 地址的限制，例如只侦听本地的连接
三、账户密码的问题最后一种情况是账户密码的问题，应付这种情况我们有个有力的工具就是查看 MySQL 的 error log， error log 记载信息的详细程度上由参数 --log-error-verbosity 进行控制的
② 数据库未启动或连接失败是怎么回事,如何去核实
你好！
先确认数据库的服务有没启动,开始--控制面板--管理工具--服务,再找到对应的数据库服务把它设置为自动启动,然后在启动.如果不行的话就很有可能是数据库坏了,最好是重装.
希望对你有所帮助，望采纳。
记得给问豆啊！
③ 魔兽世界单机版启动数据库失败
先试试右键选择文件-以管理员身份运行，试试看
行不行
。
不行的话点击
开始-对话框中输入cmd-输入lusrmgr.msc
在弹出的
本地用户和组
选择
用户，双击右侧的
administrator
常规中，把
账户已禁用
勾选去掉，并设置密码。
返回之前的，重新
开始--cmd--在命令行中输入
runas
/user:administrator
cmd.exe
完成后重新双击或者右键以管理员身份，运行程序
④ 如何查找数据库启动失败原因
重启了一次服务器后，使用> mysql -u root -p登陆是出现下面的错误：
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
于是，我检察mysql状态：
> /etc/rc.d/init.d/mysqld status
显示stop，未运行。
>/etc/rc.d/init.d/mysqld restart
Stopping mysqld: [ OK ]
MySQL Daemon failed to start.
Starting mysqld: [ FAILED]
>ps -ef | grep mysql
root 28221 27474 0 14:18 pts/0 00:00:00 grep mysql 只有这一条
至此，我可以确定，mysql无法启动。
我开始排错，首先发现/tmp/mysql.sock不存在
>vim /etc/my.cnf
socket=/var/lib/mysql/mysql .sock
/var/lib/mysql/mysql .sock同样不存在
>find / -name mysql.sock
显示为空，未查询到mysql.sock文件，mysql.sock文件丢失了。
我看网上有人说mysql.sock套接字文件可以简单地通过重启服务器重新创建得到它，
>init 6 重启命令
重启后发现错误还是那样，没有任何改变，mysql.sock重启服务器未自动生成。
接下来了解到mysql.sock是一个临时文件,在mysql启动时会自动生成,我的服务器未启动，自然就没有mysql.sock文件。
我尝试安全启动模式，mysqld_safe试图通过工作目录找到服务器和数据库，但mysqld_safe还是失败。
>mysqld_safe &
Starting mysqld daemon with databases from ....../mysql/var
STOPPING server from pid file .......pid
130802 15:17:11 mysqld ended
各种命令尝试无效的情况下，我开始了本次最大的收获----学会看错误日志。
在错误日志中，启动失败的原因极为明显，file ‘./mysql-bin。000004’ not found，failed to open！
mysql开启了bin日志功能，到数据库根目录查看该文件是存在的，可能是文件权限的问题。
>chown -R mysql:mysql /....../mysql/var
>mysqld_safe &
>/etc/rc.d/init.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK]
成功启动了！~
此时mysql.sock文件出现了，在/var/lib/mysql/mysql .sock。如下图所示，以”s”开头的文件都是socket文件。
> mysql -u root -p
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
/tmp/mysql.sock
解决这个错误很简单，因为/tmp/mysql.sock不存在，用这样的方法:
>ln -s /var/lib/mysql/mysql .sock /tmp/mysql .sock
以”l”开头的文件是软链接文件。或者可以通过修改/etc/my.cnf文件来修正它。
成功解决了！~
就是这样一个问题折腾了我这么久，错误日志让它无所遁形。查看错误日志可以明确问题所在，而不是像我之前那样盲目的找错。
俗话说授人以鱼不如授人以渔，学会查看日志，你也可以方便快捷的解决问题了。
错误使人进步，我与这个错误斗争了四个多小时，对linux的“一切皆文件”这句话有了更深的了解，对我学习文件系统管理（目录树）有很大的帮助，让我的思维真正的从windows操作系统转向成linux系统。并最终解决问题，很有成就感，我喜欢这种感觉
⑤ 打开数据库失败，登陆不了怎么办
无法打开用户默认数据库，登录失败,这也是SQL Server使用者常见的问题之一。在使用企业管理器、查询分析器、各类工具和应用软件的时候，只要关系到连接SQL Server数据库的时候，都有可能会碰到此问题。
一、原因
登录帐户的默认数据库被删除。
二、解决方法：
(一)、使用管理员帐户修改此帐户的默认数据库
1、打开企业管理器,展开服务器组,然后展开服务器
2. 展开"安全性",展开登录，右击相应的登录帐户，从弹出的菜单中选择，属性
3、重新选择此登录帐户的默认数据库
(二)、若没有其他管理员登录帐户，无法在企业管理器里修改，使用isql命令行工具
isql /U"sa" /P"sa的密码" /d"master" /Q"exec sp_defaultdb N'sa', N'master'"
如果使用Windows验证方式，使用如下命令行，将默认数据库改成非丢失的数据库：
isql /E /d"master" /Q"exec sp_defaultdb N'BUILTIN\Administrators', N'master'"
⑥ Windows服务器MySQL启动失败怎么办
方法1.
可以通过命令启动
电脑的“开始”菜单栏，找到“运行”cmd，在运行cmd框中直接输入：net
start
mysql
方法2.
控制版面-管理工具-服务
⑦ SQL数据库启动失败
检查下控制面板——管理工具——服务，里面的SQLSERVER 有没有启动。重新启动，如果文件损失造成启动失败，建议备份数据库，重新下SQL
⑧ 帮我看下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，采用排除法逐步找出错误的参数。
⑨ 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：不执行前滚的操作。