MySQL启动失败时error.log路径由配置文件log_error项决定，常见于数据目录下如/var/lib/mysql/hostname.err；需结合journalctl、权限检查及配置校验定位问题。
MySQL启动失败时error.log在哪、怎么读
绝大多数情况下，error.log 路径不是默认的 /var/log/mysql/error.log，而是由配置文件里的 log_error 项决定。先查配置：
- 运行
mysqld --verbose --help | grep "log-error"，看输出里实际生效的路径（注意是“Default”还是“Resolved”） - 如果 MySQL 曾经启动过但崩溃了，
error.log可能写在数据目录下，比如/var/lib/mysql/hostname.err（hostname是机器名） - 日志开头几行常有关键线索：比如
Can't start server: Bind on TCP/IP port表示端口被占，Plugin 'InnoDB' init function returned error指向存储引擎问题
常见权限错误：/var/lib/mysql 目录属主不对
MySQL 服务进程（通常是 mysql 用户）必须对数据目录及其子目录有完整读写权限，且不能是 root 所有。最典型现象是日志里反复出现：mysqld: Can't create/write to file '/var/lib/mysql/ibdata1' 或 Operating system error number 13 in a file operation（即 Permission denied）。
- 确认当前属主：
ls -ld /var/lib/mysql—— 正确应为mysql:mysql - 修复命令：
sudo chown -R mysql:mysql /var/lib/mysql（注意-R和结尾斜杠不加） - 别顺手
chmod 777：MySQL 会拒绝启动，要求数据目录权限 ≤ 755，且不能有 group/other 写权限
systemd 启动失败时，journalctl 比 service status 更有用
systemctl status mysql 只显示最后一行摘要，真正有用的上下文藏在 journal 里。
- 查完整启动过程：
sudo journalctl -u mysql --since "2 minutes ago" -n 100 - 特别留意带
Failed to start MySQL Community Server的那一行之前的几条日志，往往有真实原因，比如Address already in use或Cannot open /etc/my.cnf - 如果 journal 为空，说明 mysqld 进程根本没跑起来，问题大概率出在配置加载阶段（比如
my.cnf语法错误）
my.cnf 配置错误导致静默失败
MySQL 加载 my.cnf 时遇到语法错误（如漏括号、错用等号、路径不存在），不会报错退出，而是跳过该段落或直接终止初始化——结果就是服务“假死”，ps aux | grep mysql 看不到进程，error.log 里也无记录。
- 用
mysqld --defaults-file=/etc/my.cnf --validate-config主动校验配置（5.7+ 支持，低版本用--verbose --help看是否报错） - 检查
[mysqld]段落里是否有非法参数，比如把innodb_buffer_pool_size = 2G写成innodb_buffer_pool_size = 2 GB（空格不允许） - 确认
datadir路径存在且可访问：ls -ld $(grep datadir /etc/my.cnf | awk '{print $3}')
最麻烦的是配置和数据目录不匹配：比如你改了 datadir，但没迁移文件，也没清空旧目录下的 ib_logfile*，InnoDB 就会卡在恢复阶段，日志只写半句就停住。
