MySQL启动失败主因是端口占用、systemd超时、配置错误、权限问题或系统表不匹配。需依次检查3306端口、延长TimeoutStartSec、验证配置语法、确认datadir权限、执行mysql_upgrade或重建系统库。
Can't start server: Bind on TCP/IP port
这是最常见的自动重启失败原因:端口被占用。MySQL 默认尝试绑定 3306,若该端口正被其他进程(如残留的 mysqld、docker 容器、或另一个 MySQL 实例)占用,就会静默失败。
实操建议:
sudo lsof -i :3306(macOS/Linux)或 netstat -ano | findstr :3306(Windows)查占用进程kill -9 或 taskkill /F /PID 杀掉mysqld 配置文件(如 /etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf),避免端口在某处被意外改写Failed with result 'timeout')MySQL 初始化耗时较长(尤其启用了 innodb_buffer_pool_size 大内存、或数据目录损坏需崩溃恢复),但 systemd 默认只等 90 秒。超时即标记为失败,不会输出完整错误日志。
实操建议:
sudo systemctl edit mysqld,添加:[Service] TimeoutStartSec=300
sudo journalctl -u mysqld -n 100 -e,重点找 InnoDB 相关报错(如 tablespace is missing、log sequence number check failed)Starting crash recovery...,说明 InnoDB 崩溃恢复卡住,需考虑强制跳过恢复(仅限紧急恢复数据,不建议长期启用):innodb_force_recovery = 1(加到 [mysqld] 段)mysqld 进程启动后立刻退出,error log 为空或只有时间戳这通常意味着配置文件语法错误,或关键路径不可写(如 datadir、socket、pid-file 对应目录权限不对),导致 mysqld 在写日志前就 abort。
实操建议:
sudo mysqld --defaults-file=/etc/my.cnf --no-defaults --validate-config,会直接报出哪一行语法错误datadir 所有者是否为 mysql:mysql(Linux)或 _mysql(macOS),并确认 chown -R mysql:mysql /var/lib/mysql
socket 路径(如 /tmp/mysql.sock),确保父目录 /tmp 可写且未被 tmpfs 限制(某些容器或 hardened 系统会挂载 noexec,nosuid,nodev)Table 'mysql.plugin' doesn't exist 或 Unknown table 'mysql.servers'
这是 MySQL 升级后未运行 mysql_upgrade 的典型表现——系统表结构与二进制版本不匹配,导致 mysqld 初始化阶段无法加载插件或用户权限模块,从而拒绝启动。
实操建议:
mysqld --version 和 mysql --version,确保主程序和客户端大版本一致(如都是 8.0.x)--skip-grant-tables --skip-networking),再执行:mysql_upgrade -u root -p --force
mysql_upgrade,改为启动时自动执行;若仍报此类错,说明 mysql 系统库被误删或损坏,需用 mysqld --initialize-insecure 重建(仅限无重要数据的测试环境)journalctl 最后 20 行,再用 --validate-config 和 --skip-grant-tables 逐步排除,比盲目重启有效得多。