mysql启动失败主因是端口占用、systemd超时、配置错误、权限问题或系统表不匹配。需依次检查3306端口、延长TimeoutStartSec、验证配置语法、确认datadir权限、执行mysql_upgrade或重建系统库。
MySQL 启动时提示 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）查占用进程 - 确认不是合法的 MySQL 进程后，用
kill -9或taskkill /F /PID杀掉 - 检查是否有多个
mysqld配置文件（如/etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf），避免端口在某处被意外改写
systemd 服务启动超时后直接退出（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） - 停掉所有 mysqld 进程后，用旧版数据目录 + 新版 mysqld 启动一次（加
--skip-grant-tables --skip-networking），再执行：mysql_upgrade -u root -p --force - 注意：MySQL 8.0.16+ 已弃用
mysql_upgrade，改为启动时自动执行；若仍报此类错，说明mysql系统库被误删或损坏，需用mysqld --initialize-insecure重建（仅限无重要数据的测试环境）
MySQL 自动重启失败的根因往往藏在「没被看到的日志」或「被忽略的权限/路径前提」里。别只盯着 service 状态，先看 journalctl 最后 20 行，再用 --validate-config 和 --skip-grant-tables 逐步排除，比盲目重启有效得多。