mysql启动失败时error_log默认位置因安装方式而异：ubuntu/debian为/var/log/mysql/error.log，源码或homebrew为/usr/local/mysql/data/hostname.err，centos/rhel为/var/lib/mysql/hostname.err；不确定时可用mysqld --help --verbose | grep "log-error" 查找实际路径。
MySQL 启动失败时 error_log 在哪找
默认位置取决于安装方式：/var/log/mysql/error.log（Ubuntu/Debian 包安装）、/usr/local/mysql/data/hostname.err（源码编译或 macOS Homebrew），或 /var/lib/mysql/hostname.err（CentOS/RHEL）。不确定路径时，先查配置：mysqld --help --verbose 2>/dev/null | grep "log-error"，输出行末尾就是实际日志路径。
常见 error_log 报错：PID file not found 或 Permission denied
这类错误往往不是 MySQL 本身崩溃，而是启动流程卡在初始化阶段。典型现象是执行 systemctl start mysqld 后立刻返回失败，且 systemctl status mysqld 显示 “Failed with result ‘exit-code’”。
-
PID file /var/run/mysqld/mysqld.pid not found：目录/var/run/mysqld/不存在或权限不对，MySQL 进程无法写入 PID 文件 -
Can't start server: can't create PID file：同上，但更可能因mysqld进程以mysql用户身份运行，而该用户对 PID 目录无写权限 -
File './mysql/plugin.frm' not found (Errcode: 13 - Permission denied)：数据目录（如/var/lib/mysql）属主不是mysql:mysql，或 SELinux/AppArmor 拦截了访问
快速修复 PID 和权限问题的实操步骤
不要直接改 systemd 配置或强行加 --user=root 启动——这会埋下安全与稳定性隐患。
- 确认数据目录归属：
ls -ld /var/lib/mysql，如果不是mysql:mysql，运行sudo chown -R mysql:mysql /var/lib/mysql - 创建并授权 PID 目录：
sudo mkdir -p /var/run/mysqld→sudo chown mysql:mysql /var/run/mysqld - 检查
my.cnf中是否硬编码了错误的pid-file路径，比如指向了不存在的/var/run/mysqld.pid（缺子目录）；应统一为pid-file = /var/run/mysqld/mysqld.pid - SELinux 启用时，临时放行测试：
sudo setsebool -P mysqld_disable_trans 1；若生效，再用audit2why分析日志补策略，而非永久关闭 SELinux
error_log 里出现 “Starting mysqld daemon with databases from …” 就代表成功？
不一定。这只是初始化日志开头，不代表服务已监听端口或接受连接。必须继续看后续几行：
- 出现
mysqld: ready for connections或Socket: '/var/run/mysqld/mysqld.sock' port: 3306才算真正就绪 - 如果卡在
Starting crash recovery...后长时间无响应，可能是 InnoDB 表空间损坏，需用innodb_force_recovery=1启动后导出数据 - 某些云镜像预装 MySQL 会把
bind-address = 127.0.0.1写死，导致远程连不上，但这不影响本地mysql -u root -p连接，别误判为启动失败
最常被忽略的是：修改配置或权限后，没清掉残留的 mysqld.pid 文件或旧 socket 文件，systemd 会拒绝重复启动。动手前先 sudo rm -f /var/run/mysqld/mysqld.pid /var/lib/mysql/mysql.sock。
