mysql启动失败时应先查看错误日志（error log），默认路径包括/var/log/mysql/error.log、/var/log/mysqld.log或数据目录下的hostname.err，可通过grep -i "log_error"查找配置确认。
MySQL 启动失败时，先看哪个日志文件
默认情况下，MySQL 启动失败不会直接报错到终端，而是把关键信息写进错误日志（error log）。这个文件位置取决于配置，常见路径有：/var/log/mysql/error.log、/var/log/mysqld.log、/usr/local/mysql/data/hostname.err。如果不确定，查 my.cnf 里 log_error 的值：
grep -i "log_error" /etc/my.cnf /etc/mysql/my.cnf /usr/my.cnf 2>/dev/null。找不到配置项时，MySQL 通常会 fallback 到数据目录下的
hostname.err 文件。
常见 error log 报错及对应处理
打开日志后，重点盯以下几类错误行：
-
Can't start server: Bind on TCP/IP port: Address already in use：端口被占，用lsof -i :3306或netstat -tuln | grep :3306查进程，杀掉或改my.cnf中的port -
InnoDB: Unable to lock ./ibdata1 error: 11：文件被其他 mysqld 进程锁住，确认无残留进程（ps aux | grep mysql），再删ibdata1前务必确认没在运行且已备份 -
Unknown/unsupported storage engine: InnoDB：my.cnf里误加了skip-innodb或引擎插件未加载，注释掉相关行，或检查plugin_dir路径是否正确 -
Table 'mysql.plugin' doesn't exist：数据目录不完整，可能是初始化没做或误删系统表，需用mysqld --initialize --user=mysql --datadir=/path/to/data重初始化（注意：这会清空原有数据）
mysqld_safe 和 mysqld 启动方式差异影响排查
很多系统用 mysqld_safe 包装启动，它会自动重启崩溃的 mysqld，反而掩盖真实错误。临时绕过它直接运行 mysqld 更利于定位问题：
- 停服务：
systemctl stop mysql或service mysqld stop - 手动启动并前台输出：
mysqld --user=mysql --datadir=/var/lib/mysql --basedir=/usr --console（路径按实际调整） - 此时所有错误直接打印到终端，包括配置语法错误（如
my.cnf中多了一个逗号）、权限拒绝（chown -R mysql:mysql /var/lib/mysql常漏）
SELinux 或 AppArmor 拦截导致静默失败
Linux 发行版如 CentOS/RHEL 默认启用 SELinux，Ubuntu/Debian 可能启用了 AppArmor，它们可能阻止 mysqld 访问数据目录或 socket 文件，但 error log 里往往只显示“Permission denied”，不提安全模块。
- 临时禁用测试：
setenforce 0（SELinux）或sudo systemctl stop apparmor - 若禁用后启动成功，说明是策略问题，不要长期关闭，应生成对应策略：
ausearch -c 'mysqld' --raw | audit2allow -M mypolicy，再semodule -i mypolicy.pp - 检查上下文：
ls -Z /var/lib/mysql，正确应为system_u:object_r:mysqld_db_t:s0
Permission denied 可能背后是 SELinux、用户组归属、或挂载选项（如 noexec）三者之一，得逐层排除。 
