mysql服务器启动失败，绝大多数情况下不是真的坏了，而是配置文件、权限、端口或数据目录出了问题，按顺序排查就能解决。
我的mysql服务器突然启动不了,第一反应不是重装，而是冷静下来看日志，mysql其实很坦诚，它启动不起来的原因通常会写在错误日志里，只是很多人不看，或者不知道怎么定位，如果你也遇到mysql服务无法启动的情况，别急着翻车，这里有完整的排查思路。
mysql启动失败原因有哪些？从日志开始排查
mysql启动失败的常见原因其实很集中,根据行业共识，大部分问题出在配置文件、端口冲突、权限错误和数据目录状态这些环节，先说结论：先看错误日志，再根据日志里的线索去改配置、清端口、修权限，很多所谓“诡异”的启动不了，实际就是这几个基础环节拧着劲。
配置文件写错是mysql无法启动的隐形杀手
mysql的配置文件在linux下一般是/etc/my.cnf或/etc/mysql/my.cnf，windows下是my.ini，一个常见的隐形杀手是参数写错，比如把innodb_buffer_pool_size写成了innodb_buffer_pool_siz，mysql直接不认，还有路径写错，比如datadir指向了一个不存在的目录，启动时找不到数据文件，自然失败。
排查配置问题有个笨但有效的办法：先用mysqld --print-defaults看当前生效的配置，再用mysqld --validate-config校验配置有没有语法错误，如果mysql版本比较老，可以用mysqld --basedir=... --datadir=...手动前台启动，报错会直接打到终端上，比翻日志更直观。
端口被占用或权限不足导致服务起不来
3306端口被别的进程占了,是mysql启动失败的高频原因，尤其是你在同一台机器上装了多个mysql，或者有别的应用抢占了默认端口，linux下可以用netstat -tlnp | grep 3306或者ss -ltnp | grep 3306看一眼，windows下用netstat -ano | findstr 3306，如果发现不是mysql，要么杀掉占用进程，要么把mysql的端口改成3307。
权限问题也很常见,linux下mysql的数据目录必须属于mysql用户，如果你用root手动解压过数据文件，很可能所有文件都变成root的，mysql就没法读写了，解决方法是
chown -R mysql:mysql /var/lib/mysql，windows下则是服务账户没有数据目录的完全控制权，右键属性设置一下就行。
数据目录损坏和磁盘空间不足别忽略
非正常断电、强制kill进程，都可能让InnoDB表文件出现损坏，mysql启动时检查到redo log和数据文件不一致，会拒绝起来，此时错误日志里常常有corrupt或ibdata之类的字样，数据目录所在分区满了也不行，mysql需要空间来新建临时文件和写日志，磁盘空间不足时启动会一直卡住或直接退掉，用df -h看一下剩余空间，如果确实满了，清理日志或者调大分区再说。
linux和windows下mysql启动失败怎么办？分系统处理
不同系统下的处理方式有区别,但核心思路一致：看日志、验证配置、修权限、手动启动，下面分开说，方便你对号入座。
linux下mysql无法启动：查看日志和修复权限
在linux上,mysql启动失败一般通过systemd或init脚本管理，先用systemctl status mysqld看状态，如果显示failed，再用journalctl -xe查看最近的系统日志，或者直接tail -100 /var/log/mysql/error.log看mysql自己的错误日志。
权限问题是linux重灾区,如果日志里有Permission denied，检查数据目录和日志文件的权限，跑一条ls -la /var/lib/mysql，如果看到属主不是mysql，执行chown -R mysql:mysql /var/lib/mysql，SELinux也可能拦着mysql不让你读数据目录，临时关掉测试一下：setenforce 0，如果启动了，那就得给mysql的文件添加合适的SELinux上下文。
还有一种情况是/var/run/mysqld目录不存在，mysql需要在此创建socket文件，执行mkdir /var/run/mysqld && chown mysql:mysql /var/run/mysqld，再启动。
windows mysql服务启动不了：修复服务与初始化
windows上mysql服务启动不了,常见原因是服务配置里的可执行路径出了问题，或者初始化文件损坏，先在服务列表里找到mysql服务，看它能不能启动，如果提示“服务已停止”，去C:ProgramDataMySQLMySQL Server 8.0Data下找.err日志文件，这是最直接的诊断依据。
很多时候,windows下mysql无法启动是因为
my.ini里路径带空格或中文，mysql解析后找不到路径，检查一下basedir和datadir是否用了绝对英文路径，服务还没初始化的话，手动以管理员身份打开cmd，运行mysqld --initialize-insecure，这样会生成一个不带密码的root账户，然后再启动服务。
如果服务已经损坏,可以用mysqld --install重建服务，记得先删除旧服务，sc delete mysql，再重新安装。
mysql启动不了，如何保住数据并恢复？
最让人着急的是启动不了但数据还在,却不能访问，这种情况别慌，思路是尽量在不修改原数据的前提下，绕过破坏启动程序的东西。
先备份在启动失败状态下能拿走的数据
如果只是配置文件坏了,而你无法确定修改后会不会搞得更糟，先把数据目录下的.frm、.ibd和ibdata1等文件复制到别的地方，至少备份到另一个磁盘，虽然这些文件直接拷贝出来也不能直接读，但起码给了后续修复留了退路，如果日志记载是某个表损坏，你甚至可以先把其他业务文件备份出来。
如果错误日志中提到了具体哪张表坏了,可以尝试从备份中提取这张表的定义和数据，没有备份的话，就带着恢复工具去处理。
用临时参数绕过损坏配置
很多mysql启动失败其实是配置参数过于激进导致的,比如innodb_buffer_pool_size设置太大，实际内存不够分配，这种情况下，可以用mysqld --innodb-buffer-pool-size=128M --skip-grant-tables临时启动，先让数据库进到一个最小可用状态，注意，--skip-grant-tables会关闭权限验证，只建议在本地紧急运维时使用，启动成功后尽快导出数据。
如果是因为数据目录权限不对导致启动失败,也可以先用mysqld --user=root强制用root启动，然后修复目录归属，再正常启动，但这些只是临时出路，最终还是要解决配置和权限的根源问题。
预防mysql启动失败，做好这几件事
mysql触发一次启动失败,往往比修数据更花时间，与其等到出了问题再焦头烂额，不如平时就养几个好习惯。
- 每次改配置前,先备份原来的
my.cnf
my.ini，改完后用mysqld --validate-config校验。 - 关注磁盘空间,尤其是数据目录所在分区，剩余空间低于一定比例就要清理，多数情况下，日常未注意的日志文件才是撑爆磁盘的元凶。
- 定期做备份,同时记录下mysql的版本和配置参数，恢复时能快速匹配，不用猜。
- 有了云服务器或自建机房,在部署mysql之前，把系统时间、防火墙状态都检查一遍，避免Mysql启动时时钟偏移或网络限制造成外部影响。
数据无价,启动失败的修复方案里，第一优先级永远是保住数据，不是每个人的mysql启动失败都那么严重，但大多时候，一颗冷静的心加上一份检查清单，就能救回一个加班夜。
Q&A：mysql启动不了怎么办？常见问题解答
mysql启动失败时，错误日志应该去哪里找？
linux系统下,常见位置是/var/log/mysql/error.log或/var/log/mysqld.log；redhat和centos可能存放在/var/log/mysql/目录下，windows下通常在数据目录下有一份.err文件，默认路径类似C:ProgramDataMySQLMySQL Server 8.0Data，查看日志时重点看最后的几行，尤其是包含ERROR或Aborting的段落。
mysql服务无法启动，端口被占用怎么办？
先确认谁占用了3306端口,linux用lsof -i:3306，windows用netstat -ano | findstr 3306，如果占用的是其他程序，直接停掉或用保留端口的方式避让，如果占用的是另一个mysql实例，可以使用port参数把目标mysql的启动端口改到3307，改完后记得同步修改应用连接串里的端口，否则应用还是连不上。
磁盘空间不足导致mysql启动不了，应该清理哪些文件？
优先清理mysql的错误日志和慢查询日志,/var/log/mysql/下旧文件可以清理或压缩，其次检查binlog，如果binlog-expire-logs-seconds设置得太长，会积累大量binlog文件，用purge binary logs before now()释放空间，还有一个容易被忽略的是临时目录/tmp，mysql生成临时表时也需要空间，如果临时目录被占满，启动过程会毫无理由地中断，所以确认df -h /tmp也足够空。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/739329.html
