数据库服务没启动咋整，常见问题和简单应急办法分享

综合自网络运维社区常见讨论、个人经验及部分技术博客分享）

数据库服务突然罢工了,这事儿谁都可能碰上，别慌，一上来千万别想着重装系统或者格式化硬盘，那相当于病人咳嗽你直接准备后事，太极端了，咱们一步步来，从最简单的可能性开始排查，大多数时候问题都没那么严重。

第一步：先确认它是不是真的“死透了”

很多时候你以为服务挂了,可能只是界面卡了或者网络抽风，先别急着给数据库“判死刑”。

• 看看进程在不在：（来源：基础系统管理常识）在你的服务器上，打开命令行（Windows是CMD或PowerShell，Linux/Mac是终端），输入查看进程的命令，比如在Linux下，可以用 ps -ef | grep mysql（如果是MySQL的话）这样的命令，看看有没有数据库相关的进程在跑，如果根本找不到进程，那说明服务确实没启动起来，在Windows下，可以打开任务管理器，在“详细信息”里找找有没有mysqld.exe或类似名称的进程。
• 试试能不能连上：（来源：数据库连接基本操作）用你平时连接数据库的工具，比如命令行客户端、Navicat、DBeaver或者程序里的连接字符串，试着连接一下，如果报错是“无法连接到服务器”、“连接被拒绝”这类，那基本就是服务没起来或者网络不通，如果报错是“密码错误”或者“权限不足”，那至少说明服务是活着的，只是不让你进，这是另一个问题了。

第二步：对付“最常见”的几种死法

确认服务没启动后,优先检查下面这几个高频出问题的点。

1. 端口被占了：（来源：网络服务冲突常见问题）数据库服务比如MySQL默认用3306端口，PostgreSQL用5432端口，如果别的程序不小心占了这个端口，你的数据库就起不来了，检查端口占用情况，在Linux下可以用 netstat -tulnp | grep 3306，在Windows下可以用 netstat -ano | findstr 3306，如果发现是别的进程占着，要么停掉那个进程，要么去修改数据库的配置文件，给它换个端口号。
2. 配置文件写错了：（来源：配置失误导致启动失败）数据库启动时要读一个配置文件（比如MySQL的my.cnf或my.ini），如果你最近手贱改过里面的某个参数，比如路径写错了、内存设置得太大超过了机器实际内存，或者打了个错别字，服务就会启动失败。应急办法：最直接的是，如果你有修改前的备份，赶紧还原回去，如果没有，就看看数据库的错误日志（下面会讲），日志通常会明确告诉你哪一行配置有问题，临时救急，可以尝试用默认配置启动，先保证服务能跑起来。
3. 磁盘空间满了：（来源：服务器运维血泪教训）这是非常常见但容易被忽略的一点，数据库在运行和启动过程中需要写日志、需要临时空间，如果硬盘被日志文件或者别的什么文件塞满了，它肯定罢工，马上去查一下数据库所在磁盘的使用情况，Linux下用 df -h，Windows下看磁盘属性，如果真是满了，赶紧清理没用的日志文件、备份文件或者大文件。注意：删文件前最好确认一下是不是能删，别把数据库文件本身给删了。
4. 权限问题：（来源：Linux系统权限管理）在Linux系统上，数据库进程通常是以一个特定的系统用户（比如mysql用户）运行的，如果数据库文件（数据目录、日志文件）的所属用户或权限不对，这个用户没权利读写，服务也启动不了，检查一下数据目录的权限，确保它们属于正确的用户，比如用 chown -R mysql:mysql /var/lib/mysql 这样的命令改变所有者（路径换成你实际的）。

第三步：求救信号——看日志

上面都是常规操作,如果还不行，或者一开始就报错，那就必须祭出终极法宝：错误日志。（来源：所有故障排查的核心步骤）数据库启动失败时，一定会把失败的原因写在错误日志文件里，这个文件的位置通常在配置文件里指定，如果没指定，也有默认位置（比如MySQL通常在数据目录下，文件名带err字样）。

打开这个日志文件,重点看启动失败时间点附近的记录，日志可能会直接告诉你“无法创建PID文件”、“内存分配失败”、“某个表损坏了”等等，这比你自己瞎猜要准一万倍，把日志里最后的错误信息复制出来，扔到搜索引擎里，十有八九能找到现成的解决方案。

简单应急办法（先让业务跑起来）

如果问题一时半会儿解决不了,但业务又不能长时间中断，可以考虑：

• 重启大法：（来源：不是办法的办法）虽然听起来很糙，但有时候单纯是程序卡死了，重启一下服务器或者数据库服务确实能暂时恢复，但这治标不治本。
• 切换到备机：（来源：高可用架构设计）如果你有做数据库的主从复制或者集群，这时候就体现出优势了，立马把程序的数据库连接地址指向备用的那台机器，先恢复服务再说。
• 用最近的备份恢复：（来源：数据备份与恢复预案）如果数据库彻底崩了，比如数据文件损坏，而你又没有高可用环境，那就只能用之前的备份在一个新环境上恢复出一个数据库来，然后让程序连过去，这要求你必须有可用的、不是太旧的备份。

最后啰嗦一句：平时一定要定期做备份，并且要实际演练一下恢复过程，确保备份是有效的，数据库服务停了不可怕，可怕的是数据丢了。