MySQL启动失败的四大主因是依赖缺失、端口冲突、权限/SELinux限制及日志首行错误；需依次检查libaio/numactl安装、3306端口占用、datadir权限与SELinux状态、error log开头报错，并确认my.cnf加载路径。
检查 libaio 和 numactl 是否缺失
MySQL 5.7+ 在 CentOS/RHEL 系统上启动失败，常见报错是 error while loading shared libraries: libaio.so.1: cannot open shared object file 或类似 libnuma 相关提示。这不是 MySQL 自身问题，而是系统缺少底层依赖。
实操建议：
- 运行
ldd $(which mysqld) | grep "not found"查看缺失的共享库 - 确认发行版后安装对应包：
yum install -y libaio numactl（CentOS 7/8）或apt install -y libaio1 libnuma1（Ubuntu/Debian） - 注意：某些最小化安装的云服务器镜像默认不带
numactl，即使没报错也建议装上，否则可能在高并发下触发非预期的内存分配行为
验证 3306 端口是否被占用
MySQL 启动时卡在 “Starting MySQL” 或直接报 Can't start server: Bind on TCP/IP port: Address already in use，基本就是端口冲突。
实操建议：
- 用
ss -tlnp | grep :3306或lsof -i :3306查进程，注意看PID和COMMAND - 常见干扰源：另一个 MySQL 实例、MariaDB、Docker 容器里的数据库、甚至某些监控 agent 会偷偷占 3306
- 临时改端口调试？修改
my.cnf中的port=3307，但别忘了同步改bind-address和防火墙规则 - 别只查 3306 —— 如果你改过默认端口，得按实际配置查，比如
ss -tlnp | grep :3308
确认 datadir 权限和 SELinux 状态
MySQL 启动日志里出现 mysqld: Can't create/write to file 或 Permission denied，大概率是权限或安全模块拦截。
实操建议：
- 检查
datadir所在路径（通常为/var/lib/mysql）归属：ls -ld /var/lib/mysql，必须是mysql:mysql用户组 - 递归修正权限：
chown -R mysql:mysql /var/lib/mysql，但别盲目chmod 777，MySQL 对目录权限敏感（比如datadir目录不能有 group/o 写权限） - SELinux 启用时，
setenforce 0临时关闭可快速验证是否是它导致；若确认，用semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"恢复上下文
查看 error log 的真实第一行错误
很多人翻 /var/log/mysqld.log 或 /var/lib/mysql/*.err 只看最后几行，结果错过关键线索 —— MySQL 启动失败时，真正原因往往在日志最开头。
实操建议：
- 用
head -n 20 /var/lib/mysql/*.err或grep -A2 -B2 "ERROR" /var/lib/mysql/*.err | head -n 15快速定位首条 ERROR - 特别注意：
Could not open required defaults file表示my.cnf路径不对；Unknown suffix 'G' used for variable 'innodb_buffer_pool_size'是配置写错单位（应为1G而非1GB） - 如果日志为空？检查
my.cnf里是否误配了log-error路径，或者 MySQL 根本没走到初始化日志阶段（说明卡在更底层，比如用户权限或磁盘满）
端口、依赖、权限、日志——这四点覆盖了 90% 的 MySQL 安装启动失败场景。但最容易被跳过的，是反复确认 my.cnf 加载顺序和实际生效位置，尤其是当系统存在多个配置文件时。
