mysql启动失败且mysqld进程未启动时，应先用systemctl status查看失败状态和退出码，检查数据目录权限及存在性，再用--console参数手动运行mysqld获取实时报错。
MySQL 启动失败时，mysqld 进程根本没起来怎么办？
先别急着翻日志——如果 systemctl start mysql 或 mysqld_safe 执行后立刻返回、ps aux | grep mysqld 查不到进程，说明服务连初始化都没过。这时候错误日志可能压根没生成，得先看系统级线索：
- 运行
systemctl status mysql（或mysqld，取决于你的服务名），重点看Active:后面是不是failed，以及最后一行的 “Process: XXX ExecStart=…” 提示的退出码 - 检查
/var/log/mysql/error.log或/usr/local/mysql/data/hostname.err是否存在且可读；如果目录不存在、权限不对（比如mysql用户无权写入数据目录），mysqld会静默失败 - 手动试跑：
sudo -u mysql /usr/sbin/mysqld --defaults-file=/etc/my.cnf --console，加--console强制输出到终端，能直接看到第一句报错，比如Can't create/write to file '/var/lib/mysql/is_writable'
日志里出现 Table 'mysql.plugin' doesn't exist 或 Unknown table 'gtid_executed'
这是典型的数据目录不匹配：你用新版本 MySQL 启动了旧版本初始化的数据目录，或者反过来。MySQL 5.7 升级到 8.0 后首次启动必须执行 mysqld --upgrade，但如果你跳过了，或数据目录混用了，就会卡在系统表校验阶段。
- 确认版本：运行
mysqld --version和cat /usr/local/mysql/data/VERSION（如果存在）对比是否一致 - 不要直接删
mysql系统库文件！正确做法是用对应版本的mysqld初始化：比如 8.0 用mysqld --initialize --user=mysql --datadir=/var/lib/mysql，再复制旧业务库（ibd文件 +.frm或.sdi）过去，而不是整个 data 目录覆盖 - 若确定是升级遗漏，停服务后运行
mysqld --upgrade --user=mysql --datadir=/var/lib/mysql，它会自动修复缺失的系统表
Can't start server: Bind on TCP/IP port: Address already in use
端口被占是最常见的“启动成功但连不上”的假象。MySQL 启动时检测到 3306 已被占用，会写日志然后退出，但很多人只查连接，不查监听状态。
- 查谁占了端口：
sudo lsof -i :3306或sudo netstat -tulpn | grep :3306 - 注意 Docker 容器里的 MySQL 也会绑定宿主机端口，
docker ps看有没有残留容器 - 临时改端口测试：在
my.cnf的[mysqld]段加port = 3307，再启动。如果成功，基本锁定是端口冲突 - 别忽略
bind-address配置：设成127.0.0.1时，外部连不上但本地mysql -h 127.0.0.1应该可以；设成0.0.0.0才监听所有接口
日志里反复出现 InnoDB: Unable to lock ./ibdata1 error
这表示 InnoDB 共享表空间文件被另一个 mysqld 实例锁住了，常见于强制杀进程后残留锁文件，或多个实例共用同一数据目录。
- 先确认没有其他
mysqld在运行：pgrep mysqld，有就kill -9干净 - 检查
/var/lib/mysql/下是否有ibdata1.lock或mysql.sock.lock，直接删掉（确保没进程在用） - 更隐蔽的情况：SELinux 或 AppArmor 限制了文件锁操作，CentOS/RHEL 上临时关 SELinux 测试：
setenforce 0；Ubuntu 上查aa-status看是否拦截 - 如果删锁文件后仍报错，大概率是
ibdata1文件损坏，这时不要硬启，优先从备份恢复；强行启动可能导致事务回滚失败、数据不一致
真正卡住排查的，往往不是日志里那行红字，而是日志根本没写——要么路径错了，要么权限没给，要么 mysqld 连日志文件句柄都没打开就崩了。动手前先用 --console 看实时输出，比对着空日志猜强得多。
