首段给出核心答案,然后逐步展开排查思路，核心答案用加粗，内容围绕：
- 先看进程状态,区分是VMware/VirtualBox虚拟机还是云虚拟机
- systemd时代用journalctl看日志是关键
- 磁盘满、权限、库表损坏是常见元凶
虚拟机mysql重启后服务无法启动，九成是三个原因：磁盘满了、数据目录权限不对、或者InnoDB文件损坏；先用systemctl status mysqld看一眼报错，再用journalctl -xe翻日志，配合df -h查磁盘，基本能定位。 别急着卸载重装，那招只会让问题更复杂。
linux虚拟机mysql重启后启动失败的常见征兆
虚拟机重启之后,MySQL起不来的表现五花八门，但核心场景就那几类，最常见的是systemctl start mysqld敲下去，光标卡了几秒，然后报Job for mysqld.service failed because the control process exited with error code，还有一种是进程起来了，但端口没监听，mysql -uroot -p连上去直接拒绝，再有一种是启动超时，日志里全是[ERROR] InnoDB: Unable to lock ./ibdata1。
这类问题放在物理机上其实也一样,但虚拟机里有个额外变量快照和克隆带来的UUID冲突，不少人是直接从模板克隆出的虚拟机，MySQL的auto.cnf里记录的server-uuid还沿用着模板的，启动时万一碰上另一台也在跑的实例，就会出现莫名的无法启动，不过这个报错一般比较直白，日志里能看到Server UUID字样。
用systemd状态和错误码快速定位
先确认MySQL服务在systemd视角下的状态,这是第一步，执行：
systemctl status mysqld --no-pager重点不是看那一大坨文字,而是看Active那一行的状态，以及Process:后面的exit code，如果显示code=exited, status=1/FAILURE，说明进程启动时主动退出；如果是status=203/EXEC，多半是二进制的路径或权限有问题。
接着翻一下专属日志：
journalctl -u mysqld -n 50 --no-pager这一步能看到的报错信息很多,比如Can't open the mysql.plugin table、InnoDB: Operating system error number 22，这些信息直接决定了后续处理方向，业内专家指出，绝大多数MySQL无法启动的问题，光靠这一步就能定位到大概范围。
疑似数据目录损坏时的处理顺序
日志里有InnoDB相关报错时,别慌，先判断是物理损坏
还是文件系统层面的异常，虚拟机场景下，后者更常见，因为宿主机的异常断电、虚拟机强制关机，都可能让磁盘里的redo log处于不一致状态。
处理顺序有讲究,按优先级来：
- 重新mount检查一下宿主机VMFS/RAID状态，确保底层磁盘无异常
- 用
ls -lah /var/lib/mysql/看ibdata1和ib_logfile0的权限，所有权必须是mysql:mysql - 确认
/var/lib/mysql所在分区有没有剩余空间，df -h直接看 - 看SELinux是否拦截,
getenforce如果是Enforcing，建议先setenforce 0试启动
mysql服务无法启动排查思路：日志优先
很多人一遇到启动失败就百度“mysql启动不了怎么修复”，然后照着网上的命令乱试，我的建议是，别跳过日志排查这一步，日志是MySQL自己写的，它知道自己为什么死，比你猜要靠谱得多。
MySQL的日志默认位置在/var/log/mysqld.log，用tail -50 /var/log/mysqld.log看最后50行，如果这个文件是空的，可能日志轮转配置有问题，或者MySQL的启动参数没指定log-error，这时候哪怕启动失败，也会在/var/lib/mysql/目录下生成一个.err文件，同样值得看。
mysql重启后无法启动的五大高频诱因
根据经验梳理一下,重启用不了MySQL，百分之九十跑不出下面这五类：
- 磁盘空间满了，且InnoDB没法写新redo log，直接拒绝启动
- 内存不够，虚拟机的内存分配太小，MySQL在初始化buffer pool时就被OOM kill
- SELinux或AppArmor拦截了MySQL的socket或datadir文件访问
- 表损坏或redo log与数据文件不一致，多见于强制关机后
- 端口被占用，绑定的3306已经被别的进程占掉
磁盘空间这个情况挺隐蔽,因为df -h /看着还有空间，但MySQL的datadir可能挂载在独立分区上，那个分区满了，查的时候别只盯着根分区，df -h | grep /var/lib这种具体挂载点要看清楚。
针对InnoDB不一致时的恢复尝试
如果报错里出现了InnoDB: Corrupted page或page [page id: space=...]，说明innodb文件确实有损坏，这时可以试试innodb_force_recovery参数，按级别从1到6逐级尝试，每提一级都要能启动再继续，别一上来就设成6。
mysqld --innodb_force_recovery=1 --user=mysql --datadir=/var/lib/mysql设成1或2能启动的话,优先把业务数据用mysqldump导出来，然后重建实例。强制恢复模式下的实例不具备安全性，只适合抢救数据，不适合正常对外服务。
虚拟机mysql开机自启失败的玄机与解法
建了虚拟机,装上MySQL，重启后连不上数据库，发现服务根本没起来这不是MySQL坏了，而是开机自启机制压根没生效，排查思路跟启动失败不太一样，重点在于systemd的enable状态和启动顺序。
用systemctl is-enabled mysqld查一下，如果返回disabled，那说明MySQL没有注册成开机自启，把服务标记为enabled：
systemctl enable mysqld但这里有个坑,如果是用包管理器（yum/rpm）装的MySQL官方仓库版本，服务名可能是mysqld；如果用apt装的MariaDB，服务名是mysql，两个名字搞混了，enable命令会报Failed to enable unit: Unit file mysql.service does not exist。
虚拟机里网络依赖导致的服务延迟
还有一种特殊情况,MySQL服务在开机早期被拉起，但此时网卡还没拿到IP地址，尤其DHCP分配IP的虚拟网络环境下，MySQL的bind-address如果配置了具体IP（比如192.168.1.100），服务启动时IP还没就位，就会因为bind失败而退出。
解决办法是让服务等待网络就绪再加一层依赖：
systemctl add-wants multi-user.target network-online.target或者在my.cnf里把bind-address改成0.0.0或者0.0.1，这个改动需要结合业务场景，如果是给宿主机上的应用连，建议用NAT网络的固定IP或虚拟网卡IP。
用命令行直接拉起MySQL：手动启动场景
上面聊了日志和自启,现在说回手动启动，有时候systemctl拉起失败，但直接执行mysqld二进制反而能起来，这是排查边界问题的重要方法能区分是systemd配置问题还是MySQL自身问题。
直接跑一下：
sudo -u mysql mysqld --user=mysql --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock注意前台运行,不要带&，看它输出什么，如果正常起来并显示ready for connections，说明MySQL本身没问题，是systemd的service文件有瑕疵，常见的是TimeoutStartSec设太短，或者ExecStart参数和datadir不匹配。
修改systemd超时参数适配慢速磁盘
虚拟机如果用机械盘存储,磁盘IO会比较慢，MySQL启动时恢复redo log的过程耗时较长，systemd默认TimeoutStartSec=90s，如果超时就会把mysqld进程kill掉，表现为启动失败，适当放宽这个限制：
systemctl edit mysqld在打开的编辑窗里加一行：
TimeoutStartSec=300然后systemctl daemon-reload并重启服务，这种场景在NAS存储、共享存储上的虚拟机上比较典型。
mysql重启后无法启动常见问题解答
问：虚拟机重启之后mysql服务自动停止了，有没有办法让它可靠地自启动？
先确认systemctl is-enabled mysqld输出，如果是disabled就enable，另外检查my.cnf里datadir对应的挂载点是否在/etc/fstab里有_netdev选项，防止数据盘还没挂上就启动MySQL，多数情况下，加上_netdev配合systemd的After=network-online.target，就能保证虚拟机重启时MySQL等网络文件系统就绪后再启动。
问：MySQL启动时报错“Permission denied”但权限已经改成mysql用户了怎么办？
权限改好之后还有报错,多半是SELinux在捣鬼，执行getenforce看SELinux模式，如果是Enforcing，用grep mysqld /var/log/audit/audit.log | tail -20查看有没有avc denied记录，临时验证方案是setenforce 0，如果服务能正常启动，就要考虑导入正确的SELinux策略规则，或者把datadir目录的上下文设置成mysqld_db_t类型。
问：强制重启虚拟机后InnoDB表损坏，mysql启动卡在recovery阶段怎么办？
先别动数据,等待一段时间，恢复过程可能比较慢，若长时间卡住，用innodb_force_recovery=1启动，然后立即mysqldump导出关键数据，注意不要用repair工具直接修，因为MySQL层面恢复不了物理损坏的InnoDB文件，备份恢复或导出再导入才是可靠路径，恢复完成后尽快将数据迁移到新实例，避免在损坏的datadir上继续运行。
MySQL在虚拟机里重启后起不来,本质上不是玄学，是日志里白底黑字写着的具体错误，把journalctl -u mysqld和datadir目录下的err日志当作第一手信息源，结合磁盘空间、SELinux、systemd超时这几个高频坑逐一排除，多数情况下能在五分钟内解决。卸载重装是最后手段，不是默认选项，排查日志和检查基础环境能让你的虚拟机MySQL快速恢复。