MySQL 启动失败需按顺序排查：确认服务名（如mysqld）、检查3306端口与进程、查错误日志路径、验证my.cnf配置及权限、检查datadir初始化与磁盘状态。
检查 MySQL 服务是否真的没启动
有时候 systemctl status mysql 或 service mysql status 显示 “inactive” 并不意味着进程没跑，可能是服务名不一致（如 mysqld 而非 mysql）。在 CentOS/RHEL 系统上常见服务名为 mysqld，Ubuntu/Debian 上可能是 mysql 或 mysqld，取决于安装方式（包管理器 vs 二进制 tar 包）。
- 运行
ps aux | grep mysqld查看是否有残留进程 - 用
sudo netstat -tlnp | grep :3306确认端口是否被占用（哪怕没启成功，旧进程可能卡在监听状态） - 检查实际服务名：
systemctl list-unit-files | grep mysql
查看错误日志定位根本原因
MySQL 启动失败几乎必然写入错误日志，但日志路径容易被忽略。默认位置因安装方式而异：
- 使用
apt（Ubuntu/Debian）：日志通常在/var/log/mysql/error.log或/var/log/syslog中搜索mysqld - 使用
yum（CentOS/RHEL）：多为/var/log/mysqld.log - 二进制安装：由
my.cnf中的log-error配置项指定，常见于/usr/local/mysql/data/hostname.err
务必用 sudo tail -n 50 /path/to/error.log 查看末尾，重点关注最后一段 “ERROR” 行，比如：
2024-04-10T08:22:14.123456Z 0 [ERROR] InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size...
这类提示直接指向配置或文件损坏问题，不是单纯重启能解决的。
检查 my.cnf 配置是否合法且路径正确
MySQL 启动时会按固定顺序读取多个 my.cnf 文件（/etc/my.cnf、/etc/mysql/my.cnf、$MYSQL_HOME/my.cnf、~/.my.cnf），后加载的会覆盖前面的。一个常见坑是：用户手动编辑了 /etc/my.cnf，但实际生效的是 /etc/mysql/my.cnf，导致改了白改。
- 用
mysqld --help --verbose 2>/dev/null | grep "Default options"查看实际读取的配置文件路径 - 用
mysqld --validate-config（MySQL 5.7.16+）验证配置语法是否正确；若报错如unknown variable 'skip-locking'，说明用了旧版废弃参数 - 特别注意
datadir路径权限：MySQL 进程用户（通常是mysql）必须对目录有读写权限，且 SELinux（RHEL/CentOS）可能阻止访问，需运行sudo setsebool -P mysqld_disable_transitive 1或临时关闭测试
初始化数据目录失败的典型场景
首次安装后未初始化 datadir，或初始化中断导致目录不完整，是服务无法启动的高频原因。例如执行 mysqld --initialize 后没记录临时密码，又误删了 ibdata1 或 mysql 系统库目录。
- 确认
datadir是否为空或含必要子目录（mysql/、performance_schema/、sys/） - 若确定要重来，先停服务、清空
datadir、再用mysqld --initialize --user=mysql --datadir=/path/to/data初始化（注意加--user避免权限问题） - 初始化后检查
error.log末尾是否输出类似A temporary password is generated for root@localhost: xxxxxx—— 没这行说明初始化失败
最易被忽略的是：某些云镜像或 Docker 镜像把 datadir 挂载到只读文件系统，或者磁盘满（df -h）、inode 耗尽（df -i），这些不会直接报错“磁盘满”，而是表现为 ib_logfile 写入失败或崩溃退出。
