服务器挂了本地MySQL也起不来，根本原因通常不是服务器宕机本身，而是宕机引发的连锁反应：数据文件损坏、磁盘空间耗尽、进程残留，或者主从复制状态卡死，按日志一步步排查，多数情况都能救回来。
服务器挂了本地mysql起不来，先分清这三种场景
很多人遇到这种情况第一反应是“服务器坏了，本地数据库也中邪了”，我跟你讲，MySQL这个老伙计不会无缘无故罢工，它起不来一定有理由，而且这个理由往往和服务器宕机脱不了干系,但要看你俩是什么关系。
- 本地MySQL是服务器数据库的从库或者缓存。 服务器宕机导致主从复制中断，从库一直在等待主库的binlog，积压了大量日志没地方去，最后把磁盘或内存吃满,直接把自己搞崩溃。
- 本地MySQL和服务器共用一套数据目录或者网络存储。 服务器挂掉后，存储锁没释放，本地实例拿不到读写权限,自然起不来。
- 时间巧合，本地MySQL本来就半死不活。 服务器宕机的时候，你正巧在重启本地数据库，但本地早在之前就埋了雷，比如配置改坏了、端口被占,结果锅全甩给了服务器。
真实情况里，我见过最多的还是第一种，很多人本地搭了从库来分担线上压力，服务器一挂，从库没爹没娘，回放线程堵死，再启动就报各种复制错误，所以先想清楚：你本地MySQL跟那台服务器到底有没有数据层面的依赖关系。
mysql启动失败原因排查，从这五步按顺序来
不要一头扎进去就重装数据库，以下步骤每步都能快速验证原因,多数情况下能让你少折腾半天。
先看错误日志，别瞎猜
MySQL起不来，一定会留下蛛丝马迹，日志文件一般在Linux的/var/log/mysql/error.log，Windows下则在数据目录里,你可以用这个命令直接看末尾：
tail -n 100 /var/log/mysql/error.log
如果日志里有InnoDB: Corrupted page或者space id字样，基本可以认定是数据文件在服务器断电或异常宕机时出现了损坏，如果是Can't start server: Bind on TCP/IP port，那就是端口被占用，跟服务器挂了没有直接关系，纯粹是本地端口冲突，还有[ERROR] Can't open and lock privilege tables这类，多半是表文件权限不对，日志能告诉你90%的真相,剩下的就要靠下面几步排查。
杀残留进程，释放锁文件
服务器宕机时，本地MySQL进程可能没被系统正常回收，残留的
mysqld进程还攥着pid文件和socket不放，新进程启动时会发现“有人在用”,自然拒绝起来。
Linux下执行：
ps -ef | grep mysqld
Windows下用管理员开命令提示符：
netstat -ano | findstr :3306
看到多个相同进程或者PID还占着3306端口,先请它们走：
kill -9 进程ID
然后确认数据目录下的.pid和.sock文件是否存在，如果文件还在，手动删掉再启动,这一步在简单场景下非常管用。
检查磁盘空间和文件权限
服务器宕机后，如果binlog或者日志文件疯狂增长，本地磁盘分分钟被塞满，MySQL启动时需要往datadir写临时文件，磁盘满了它连临时文件都创建不了,干脆罢工。
跑一下：
df -h
看分区使用率，超过90%，赶紧清掉老的binlog和错误日志，另外别忘了看一眼数据目录的权限，特别是从服务器挂掉后如果恢复工具改过属主，mysql用户可能没有读写权限了,执行：
chown -R mysql:mysql /var/lib/mysql
强制把属主改回来，权限不对时，启动日志会直接提示Permission denied。
InnoDB数据文件损坏怎么恢复
服务器异常掉电或者宕机，最难处理的就是InnoDB引擎的ibdata1和ib_logfile0损坏，行业共识认为，这种损坏很大概率来自写入过程中进程被杀,页数据只写了一半。
你可以先在配置文件my.cnf的[mysqld]下面加一行：
innodb_force_recovery=1
用1级恢复模式跳过损坏页尝试启动，如果还起不来，再逐级调到2、4、6，但不能一直在恢复模式里跑正常业务，能启动后立刻用mysqldump导出所有数据，然后删掉数据目录重新初始化，再把导出的数据导入，这个操作要求动作快，恢复模式下InnoDB是只读的,不能做写入操作。
检查主从复制状态
如果你的本地MySQL确实是从库，服务器挂掉后主从线程会中断，重启本地实例时，有时候会卡在复制状态上一直等待,表现为启动后无法正常响应应用请求。
连上MySQL执行：
SHOW SLAVE STATUSG
看Slave_IO_Running和Slave_SQL_Running是不是都是Yes，如果一个No一个Yes，先执行STOP SLAVE;，然后在服务器恢复后重新获取主库的binlog文件名和pos位置，执行CHANGE MASTER TO重新指过去，这里要提醒一下，不要直接RESET SLAVE，那样清掉全部复制关系后，你得从头配置,很麻烦。
怎么让本地mysql在服务器宕机后快速恢复，实操步骤
上面排查完，下面这套组合拳能应对大部分情况，按顺序执行,别跳步。
用临时参数绕开损坏点
先备份一份my.cnf,然后只保留以下最简配置启动：
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock innodb_force_recovery=1
注释掉其他所有插件和参数，避免某一段配置崩溃导致启动失败，如果启动成功,立刻：
mysqldump -u root -p --all-databases > all.sql
导出后把innodb_force_recovery改回0，再处理原数据目录，如果1级还是启动失败，就逐步调整到2、4、6，注意级别越高，可用功能越少,但能救命。
重建数据目录，导入备份
当数据文件损坏到无法修复，就别心疼了,把原目录改名：
mv /var/lib/mysql /var/lib/mysql_bak
创建新目录并初始化：
mkdir /var/lib/mysql chown mysql:mysql /var/lib/mysql mysqld --initialize
初始化后正常启动，再导入之前的all.sql，这个过程依赖于你还留着mysqldump的备份，如果从来没有备份，那就要考虑直接扫描mysql_bak里的ibd文件，在另一个实例中通过ALTER TABLE ... IMPORT TABLESPACE方式恢复，这个操作比较复杂，涉及手工匹配表结构,属于亡羊补牢的做法。
服务器恢复后，重新拉齐主从关系
服务器重新起来后,去主库执行：
SHOW MASTER STATUS;
得到File和Position,回到本地从库执行：
STOP SLAVE; CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='同步账号', MASTER_PASSWORD='密码', MASTER_LOG_FILE='上一步得到的File', MASTER_LOG_POS=上一步得到的Position; START SLAVE;
跑完再看SHOW SLAVE STATUS
，两个线程都变成Yes就说明跟主库又握手成功了，如果服务器宕机前用的是GTID模式，那更简单，直接配置MASTER_AUTO_POSITION=1就行。
提前做四件事，服务器宕机别拖累本地数据库
这次能救回来，不代表下次还这么走运，本地数据库和线上服务器之间，最好做到物理隔离、逻辑独立。
- 独立部署：不要让本地MySQL直接依赖远程服务器提供任何服务，比如DNS解析、鉴权、存储挂载,你本地就干本地的事。
- 开启binlog并定期备份：就算本地是小库，也要养成备份习惯，普通用户用
mysqldump --single-transaction每周备份一次就够。 - 配置自动重启：Linux上可以写个systemd服务，设置
Restart=on-failure，MySQL一挂就会自动拉起,别指望哪天宕机后手动去救。 - 用容器隔离环境：Docker里跑一个MySQL映射好数据卷，出问题直接删容器重建，效率比修复快得多，前提是数据卷挂在本地,不放网络存储。
先说清楚，这些手段防的是“意外”，不能防“手贱”，配置改错、权限乱给、日志文件被删,再多的自动化都扛不住。
常见问题快答
服务器挂了本地mysql启动不了，能强制启动吗？
不建议直接强制跳过全部检查，先用mysqld --verbose --help查看配置是否正常，再用systemctl start mysql看报错信息，最稳妥的方式是设置innodb_force_recovery=1，只跳过损坏页，保留一致性检查后启动，强制启动前不留下恢复手段,容易二次损坏数据。
mysql启动失败原因有哪些高频场景？
高频的包括端口被占、磁盘满了、InnoDB文件损坏、表权限不对、binlog没清理干净、主从复制卡住，其中最容易被忽略的是残留的mysqld进程，服务器宕机后系统自动有systemd迁移服务，经常导致旧进程没被杀掉，新进程就起不来，用ps -ef | grep mysqld看一下,干净利落。
本地mysql跟服务器没有主从关系，为什么服务器挂了本地也跟着出问题？
如果没有任何数据依赖，那大概率是本地MySQL自身也有运行缺陷，只是服务器宕机让你注意到了它，检查一下本地机器的资源占用，比如可用内存是不是太低，或者磁盘是不是早就快满了，多数情况下，这类问题不是服务器和本地之间的连接造成的，而是本地环境本就接近临界点,服务器宕机带来的额外负载或监控指向让它暴露出来。