error.log路径应通过mysqld --verbose --help | grep "log-error"命令查询“resolved”路径确定；若无日志，需用journalctl -u mysql查启动失败原因。
error.log在哪？别猜，用命令直接问mysqld
MySQL启动失败时，error.log路径不是固定的，硬背默认值容易翻车。最稳的方式是让mysqld自己说：运行mysqld --verbose --help 2>/dev/null | grep "log-error"，看输出里标着“Resolved”或“Default”的那条路径——它才是当前生效的日志位置。
常见但不可靠的“默认”路径有：/var/log/mysql/error.log（Debian/Ubuntu）、/var/log/mysqld.log（RHEL/CentOS）、/usr/local/mysql/data/hostname.err（源码或Homebrew安装）。如果mysqld连配置都没加载成功，日志可能根本没写，这时journalctl -u mysql --since "2 minutes ago"反而更准。
日志里看到“Address already in use”就停手查端口
这是启动失败最常出现的报错之一，说明mysqld尝试绑定3306端口失败。别急着改配置，先确认是不是真被占了：
- Linux下执行
sudo lsof -i :3306或sudo netstat -tuln | grep :3306，看PID和COMMAND列 - 如果PID对应的是另一个
mysqld进程，说明有残留实例没关干净，sudo kill -9 PID后删掉/var/run/mysqld/mysqld.pid - 如果是
node、postgres或java占了，要么停掉它，要么在my.cnf里改port = 3307再试 - Windows上用
netstat -ano | findstr :3306，再用tasklist | findstr "PID"确认进程名
日志报“Can't create/write to file”大概率是权限或路径错了
这类错误往往出现在datadir、pid-file或socket路径上，不是MySQL坏了，而是它根本进不去指定目录：
- 检查
datadir是否真实存在：ls -ld /var/lib/mysql，如果不是mysql:mysql属主，立刻执行sudo chown -R mysql:mysql /var/lib/mysql - 确认
pid-file路径的父目录可写：/var/run/mysqld/经常不存在，得手动建：sudo mkdir -p /var/run/mysqld && sudo chown mysql:mysql /var/run/mysqld -
my.cnf里写的路径别带错别字，比如pid-file = /var/run/mysqld.pid（缺/mysqld/子目录）就会失败，应改为pid-file = /var/run/mysqld/mysqld.pid - SELinux启用时，
setsebool -P mysqld_disable_trans 1能临时绕过拦截，但只是验证手段，别长期开着
日志空或只有“Starting mysqld daemon…”就说明配置没加载成功
如果error.log里只有一两行初始化日志，后面戛然而止，或者压根没新内容，问题不在运行时，而在启动前——mysqld甚至没走到初始化数据库那步：
- 用
sudo mysqld --defaults-file=/etc/my.cnf --validate-config强制校验语法（MySQL 5.7+支持），报unknown variable就说明参数名写错或版本不兼容 - 检查
[mysqld]段落里有没有漏括号、多等号、路径不存在（比如basedir = /usr/local/mysql但实际装在/opt/mysql） - 删掉所有自定义配置，只留最简
[mysqld]段，再逐步加回，定位哪一行触发静默退出 - 手动前台启动试试：
sudo -u mysql mysqld --console，错误会直接打到终端，比看日志更及时
真正卡住的地方，往往不是报错最显眼的那一行，而是前面某个路径拼错、权限没给、或SELinux策略挡路——这些细节在日志里可能只体现为“没日志”，需要主动验证，不能等它告诉你。
