MySQL启动失败排查指南：常见问题与解决方案

1. MySQL启动失败的常见场景与初步诊断

当你在终端输入systemctl start mysql或service mysql start后看到"(code=exited, status=1/FAILURE)"这个错误提示时，通常意味着MySQL服务在启动过程中遇到了致命错误。这个状态码是systemd服务管理器的标准输出，其中status=1表示进程以非正常状态退出。

首先我们需要查看完整的错误日志，这是排查问题的第一步。在Linux系统中，MySQL的日志通常位于以下几个位置：

• /var/log/mysql/error.log（Debian/Ubuntu默认路径）
• /var/log/mysqld.log（CentOS/RHEL默认路径）
• 如果通过源码编译安装，可能在编译时指定的数据目录下

使用以下命令可以快速查看最近的错误信息：

bash复制sudo journalctl -u mysql.service -n 50 --no-pager

或者直接查看日志文件：

bash复制sudo tail -n 100 /var/log/mysql/error.log

注意：如果日志文件不存在，可能是权限问题导致MySQL无法创建日志文件。可以尝试手动创建并设置正确权限：

bash复制sudo touch /var/log/mysql/error.log
sudo chown mysql:mysql /var/log/mysql/error.log

2. 权限问题导致的启动失败及解决方案

2.1 数据目录权限配置错误

这是最常见的启动失败原因之一。MySQL服务运行时需要对其数据目录（通常是/var/lib/mysql）有读写权限。如果权限设置不正确，会导致服务无法启动。

检查当前权限：

bash复制ls -ld /var/lib/mysql

正常输出应该类似：

code复制drwx------ 5 mysql mysql 4096 Jun 15 10:23 /var/lib/mysql

如果所有者不是mysql用户，需要修正权限：

bash复制sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 700 /var/lib/mysql

2.2 AppArmor/SELinux安全限制

在某些Linux发行版（如Ubuntu）中，AppArmor可能会阻止MySQL访问必要资源。可以通过以下命令检查：

bash复制sudo aa-status | grep mysql

如果AppArmor确实限制了MySQL，可以尝试临时禁用：

bash复制sudo systemctl stop apparmor
sudo systemctl disable apparmor

或者更安全的方式是调整AppArmor配置：

bash复制sudo vim /etc/apparmor.d/usr.sbin.mysqld

在文件中添加必要的权限规则后重新加载配置：

bash复制sudo systemctl reload apparmor

对于使用SELinux的系统（如CentOS），可以检查审计日志：

bash复制sudo ausearch -m avc -ts recent

临时解决方