mysql启动失败时应优先检查error log路径（如/var/log/mysql/error.log）及内容，常见错误包括端口占用、数据目录损坏、系统表不兼容、文件权限问题；再验证my.cnf语法与datadir/port等参数；可手动以--console模式运行mysqld诊断；最后排查系统资源、selinux、内核参数等底层依赖。
检查 MySQL 错误日志路径和内容
MySQL 启动失败时，error log 是第一手线索。默认位置因安装方式而异：/var/log/mysql/error.log（deb 系统）、/var/log/mysqld.log（rpm 系统），或由 my.cnf 中的 log_error 配置项指定。
执行 sudo tail -n 50 /var/log/mysql/error.log 查看末尾报错。常见现象包括：
-
Can't start server: Bind on TCP/IP port: Address already in use—— 端口被占用 -
Table 'mysql.plugin' doesn't exist—— 数据目录损坏或初始化不完整 -
Incorrect definition of table mysql.db—— 系统表结构不兼容（如升级后未运行mysql_upgrade） -
Operating system error number 13 in a call to fcntl()—— 文件权限问题（/var/lib/mysql所属用户不是mysql）
验证配置文件语法与关键参数冲突
MySQL 启动时会读取 my.cnf（通常在 /etc/my.cnf、/etc/mysql/my.cnf 或 /usr/etc/my.cnf），多个路径叠加可能导致隐性冲突。
使用 mysqld --defaults-file=/etc/my.cnf --validate-config 检查语法是否合法；若提示成功，再用 mysqld --defaults-file=/etc/my.cnf --verbose --help | grep "datadir\|port\|socket" 确认实际生效值。
高频踩坑点：
-
datadir指向不存在的路径，或路径下无ibdata1和mysql/子目录 -
bind_address = 127.0.0.1与skip-networking共存导致 socket 连接也失效（部分旧版本行为异常） -
innodb_buffer_pool_size设得过大（如 >80% 物理内存），触发 OOM killer 杀死进程，日志里只显示 “Killed”
手动以安全模式启动并观察输出
绕过常规服务管理器，直接运行 mysqld 可暴露更底层错误：
sudo -u mysql mysqld --skip-grant-tables --skip-networking --console
该命令禁用权限校验和网络连接，强制输出到终端。若仍失败，说明是数据层或配置硬伤；若成功，则问题大概率出在权限表或插件加载环节。
注意：
- 必须用
mysql用户运行，否则可能因文件所有权拒绝访问datadir -
--console是关键，避免日志被重定向而丢失即时信息 - 不要长期使用
--skip-grant-tables，仅用于诊断
确认系统资源与依赖状态
MySQL 不是孤立运行的。以下基础条件缺失会导致静默失败：
-
systemd下检查依赖：运行systemctl list-dependencies --reverse mysqld，确认local-fs.target和network.target已就绪 - 磁盘空间不足：
df -h /var/lib/mysql，特别是ibtmp1文件增长失控时会占满空间 - SELinux 强制限制（CentOS/RHEL）：
sudo ausearch -m avc -ts recent | grep mysqld，若看到 denied 记录，临时用setenforce 0测试是否为根源 - 内核参数不满足：
vm.swappiness过高或fs.file-max不足，在高并发启动场景下可能触发资源分配失败
真正棘手的问题往往藏在这些边缘条件里——比如 datadir 在 LVM 逻辑卷上但卷组未激活，或者 systemd 的 ProtectHome=true 阻止了对 /var/lib/mysql 的写入，这类问题不会在 MySQL 日志里体现，只能从系统层反推。
