MySQL 启动失败时先看 error.log
里最后一段错误
MySQL 启动失败几乎从不报“启动失败”四个字，它只默默把关键线索写进日志。默认路径通常是：
/var/lib/mysql/hostname.err（Linux）或
C:\ProgramData\MySQL\MySQL Server X.X\Data\hostname.err（Windows）。直接用
tail -n 50 /var/lib/mysql/*.err或打开文件末尾，重点找带
ERROR、
Can't start、
Address already in use、
Table 'mysql.plugin' doesn't exist的行。
常见现象：
服务进程没起来，但systemctl status mysqld显示 “active (exited)” —— 实际是启动脚本跑完就退出了，根本没进入守护状态
mysql -u root -p报
Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'—— socket 文件不存在，大概率 mysqld 根本没跑起来 日志里反复出现
InnoDB: Unable to lock ./ibdata1—— 上次异常关闭后残留锁文件或崩溃未恢复
端口被占、配置错、权限不对这三类最常导致启动失败
不是所有报错都藏在日志深处，有些问题一眼就能定位：
端口冲突：运行netstat -tuln | grep :3306或
lsof -i :3306，确认没有其他 mysqld、docker 容器或测试程序占着
3306。改端口要在
my.cnf的
[mysqld]段加
port = 3307，别只改客户端配置 配置文件语法错误：运行
mysqld --defaults-file=/etc/my.cnf --validate-config（MySQL 5.7.16+ 支持），会直接提示哪一行出错。常见低级错误：
innodb_buffer_pool_size = 2G写成
innodb_buffer_pool_size = 2GB（单位不能带 B）；
skip-networking后面多加了
=1datadir 权限不对：MySQL 进程用户（通常是
mysql）必须对
datadir目录有读、写、执行权限。用
ls -ld /var/lib/mysql看属主，再用
chown -R mysql:mysql /var/lib/mysql修正。注意：别顺手
chmod 777，InnoDB 会拒绝启动
mysqld --initialize
和 mysqld --initialize-insecure
别混用
初始化数据目录时选错命令，会导致后续启动卡在
Starting MySQL.. ERROR!，日志里出现
Unknown suffix '.' used for variable 'innodb_log_file_size'或空密码无法登录。
mysqld --initialize：生成随机 root 密码，写在 error.log 最后一行，形如
A temporary password is generated for root@localhost: aB3#xQ9!mKpL。必须用这个密码首次登录后立刻改密
mysqld --initialize-insecure：root 密码为空，适合开发环境快速验证。但如果之前用过
--initialize初始化过，又切回 insecure，InnoDB 可能因系统表不匹配而拒绝加载 ⚠️ 重要：每次运行初始化命令前，必须清空
datadir（或重命名），否则会报
A mysqld process already exists或直接跳过初始化，导致后续启动找不到系统表
强制恢复 InnoDB 时慎用 innodb_force_recovery
当日志里反复出现
InnoDB: Database page corruption或
Cannot allocate memory for the buffer pool，且普通重启无效，才考虑强制恢复。但它不是万能解药，而是“只读抢救模式”： 取值范围是
1到
6，从
1开始试，逐步加大。例如在
my.cnf的
[mysqld]下加：
innodb_force_recovery = 1
level=1：忽略检查点失败；
level=4起会禁用 insert/update/delete，只能 select；
level=6几乎只允许访问部分系统表 一旦能启动，立刻用
mysqldump导出还能读的数据，然后删掉整个
datadir，重新
--initialize，再导入 —— 不要长期带着
innodb_force_recovery运行
真正棘手的不是报错本身，而是错误日志里夹杂着上一次崩溃的残留信息，或者配置项之间隐性冲突（比如
innodb_log_file_size改了但没删旧日志文件）。动手前先确认你改的是哪个
my.cnf（
mysqld --help --verbose | grep "Default options"可查加载顺序），再盯住 error.log 的时间戳和最后 20 行——大多数时候，答案就在那里，只是被滚动日志盖住了。
