MySQL启动失败需先查错误日志定位原因：包管理器安装日志在/var/log/mysql/error.log等，二进制安装看my.cnf中log_error配置，或用--console输出到终端；常见原因包括端口占用、残留进程、数据目录损坏、权限错误、配置语法错误、磁盘满、内存不足、SELinux限制及缺少libaio依赖。
MySQL 启动失败通常不是单一原因导致的，需结合错误日志快速定位。最关键是先看日志，再针对性处理，而不是盲目重启或修改配置。
查看 MySQL 错误日志定位根本原因
MySQL 启动失败时，错误信息基本都记录在错误日志中（默认路径因安装方式而异）：
- 通过包管理器安装（如 Ubuntu 的 apt、CentOS 的 yum）：日志通常在 /var/log/mysql/error.log 或 /var/log/mysqld.log
- 通过二进制解压安装：检查 my.cnf 中 log_error 配置项指定的路径，常见于 /usr/local/mysql/data/hostname.err
- 启动时加 --console 参数可临时将错误输出到终端：例如 mysqld --defaults-file=/etc/my.cnf --console
常见原因及对应修复方法
根据日志中的关键词，快速判断并处理：
- “Can’t start server: Bind on TCP/IP port”：端口被占用。执行 netstat -tuln | grep :3306 或 lsof -i :3306 查进程，杀掉冲突程序或修改 my.cnf 中的 port 值
- “InnoDB: Unable to lock ./ibdata1” 或 “Another MySQL daemon is already running”：残留 pid 文件或进程未退出。检查 pid-file 指定路径（如 /var/run/mysqld/mysqld.pid），删除该文件后重启；同时用 ps aux | grep mysql 确认无残留 mysqld 进程
- “Table 'mysql.plugin' doesn't exist” 或 “Unknown table engine 'InnoDB'”：数据目录损坏或初始化不完整。可尝试用 mysqld --initialize-insecure --user=mysql --datadir=/var/lib/mysql 重新初始化（注意备份原有 data 目录！）
- “File './mysql/user.MYD' not found”：权限问题。确保 /var/lib/mysql（或自定义 datadir）目录归属为 mysql:mysql，且权限为 755；子文件一般为 644，目录为 755
配置文件语法或路径错误排查
my.cnf 写错一个字符就可能导致 mysqld 拒绝启动：
- 用 mysqld --defaults-file=/etc/my.cnf --verbose --help | head -20 测试配置是否可被正确读取，无报错才说明语法基本合法
- 检查 basedir 和 datadir 路径是否存在、拼写是否正确，路径末尾不要多加斜杠
- 注释符必须是 # 或 ;，// 或 /* */ 会导致解析失败
- 避免在 [mysqld] 段落下添加客户端专用参数（如 [client] 下的 user/password），部分旧版本会报错
系统资源与依赖检查
容易被忽略但实际高频触发：
- 磁盘空间满：df -h 查看 /var/lib
/mysql 所在分区，清理日志或 binlog（PURGE BINARY LOGS BEFORE '2025-01-01';） - 内存不足（尤其 InnoDB buffer_pool_size 设置过大）：临时注释掉 innodb_buffer_pool_size，或调小至物理内存的 50% 以内再试
- SELinux 或 AppArmor 限制（Linux）：临时禁用测试（setenforce 0 或 sudo systemctl stop apparmor），确认是策略问题后按需调整规则
- 缺少 libaio 等依赖（CentOS/RHEL）：运行 yum install libaio 补齐
/mysql 所在分区，清理日志或 binlog（PURGE BINARY LOGS BEFORE '2025-01-01';）
