mysql启动失败时，真正原因全在mysql自身错误日志里，而非systemd日志；应优先查看/var/log/mysql/error.log等路径的日志文件，或用mysqld --console手动启动直接输出错误。
直接看 MySQL 自己写的错误日志，别翻 systemd 的 journal
systemd 报 Failed to start 或 code=exited, status=1/FAILURE 只说明 mysqld 进程启动后立刻退出了，真正原因全在 MySQL 自己的日志里。journalctl 里基本只有“Main process exited”这种套话，没用。
优先按这个顺序找日志文件：
-
/var/log/mysql/error.log—— Debian/Ubuntu 系 apt 安装默认位置 -
/var/log/mysqld.log—— CentOS/RHEL 系 yum 安装常见路径 -
/var/lib/mysql/*.err—— 编译安装或旧版本常把日志直接写在数据目录下
如果都找不到，用 mysqld --user=mysql --console 手动启动一次，错误会直接打到终端——这招能绕过配置里 log_error 路径写错导致“静默失败”的坑。
grep ERROR 和 Aborting 是最快定位方式
日志里信息杂乱，别从头读。直接搜这几个关键词，90% 的启动失败原因就藏在里面：
-
ERROR—— MySQL 明确认定致命错误，必须处理 -
Aborting—— 启动中途放弃，后面几行通常跟着具体原因 -
Can't open或Unable to lock—— 文件权限、路径不存在、或 ibdata1 被其他 mysqld 实例锁住 -
Address already in use—— 3306 端口被占，lsof -i :3306查进程 -
Permission denied——log_error指向的路径 MySQL 用户（通常是mysql）没写权限
注意：有些 InnoDB 错误只标 [Warning]，比如 Cannot open ./ibdata1，别跳过。
my.cnf 配置错会导致“不报错也不写日志”
如果日志文件本身路径配置错了（比如 log_error = /var/log/mysql/error.log，但 /var/log/mysql 目录不存在或权限不对），mysqld 会连错误都记不了，直接静默退出。
这时候必须靠验证工具提前发现问题：
- 运行
mysqld --defaults-file=/etc/my.cnf --validate-config（MySQL 5.7.16+ 支持） - 若提示
unknown variable 'innodb_locks_unsafe_for_binlog'，说明用了已废弃参数，删掉就行 - 若提示
Can't read dir of '/etc/mysql/conf.d/'，检查该目录是否存在、是否mysql用户可读
特别小心 datadir、socket、pid-file 这些路径：必须真实存在，且 mysql:mysql 可读写执行。
systemd 报 Unit not found 时，日志根本还没机会生成
如果错误是 Failed to start mysql.service: Unit not found，说明 mysqld 根本没走到启动逻辑——systemd 压根不认识这个服务。
此时不是查日志的问题，而是先确认：
-
ls /usr/lib/systemd/system/mysqld.service或/lib/systemd/system/mysql.service是否存在（不同发行版路径不同） -
which mysqld能否返回路径？返回空说明 MySQL 二进制都没装上 -
systemctl is-enabled mysqld返回disabled就得先systemctl enable mysqld
这类问题下，error.log 甚至都还没被创建，盯着日志看只会浪费时间。
