数据库服务启动失败，这事儿有多闹心，干过运维的都懂。你掐着表算好了凌晨两点更新，咖啡都泡好了，结果systemctl status一敲，红字报错，服务起不来。更气人的是，日志里就一句含糊其辞的“ERROR”，连个具体行号都不给。别急，我踩过的坑比你可能见过的报错还多，今天就把那些最常见的启动失败原因，一个个掰开揉碎了讲给你听，顺便把排查步骤也捋清楚。
第一个要查的，永远是端口占用。这毛病特别隐蔽，尤其在你同时跑着多个实例或者旧服务没杀干净的时候。MySQL默认3306，PostgreSQL是5432，Redis是6379，你觉着自己配置没问题，但一启动就提示“Address already in use”。这时候别瞎猜，直接netstat -tlnp或者ss -lntp看一眼，哪个进程占着端口一目了然。有时候是之前测试留下的僵尸进程，有时候是监控脚本自己连着的长连接没释放。kill掉那个PID，再启动就正常了。但注意，杀进程之前确认一下是不是别的业务在用的，误杀了生产库，那锅可就得你背了。
第二个高频坑，是配置文件权限和属主不对。数据库服务为了安全，通常以专用用户运行，比如mysql用户或者postgres用户。你拿root把配置文件改了，权限还是644，但目录属主变成了root，那服务一启动就报“Permission denied”。这事儿在从备份恢复数据目录的时候尤其常见——你从另一台机器tar打包过来，解压后忘了chown -R。排查步骤很简单：ls -l看看数据目录和配置文件的属主，不对就chown回来。还有个细节，有些数据库对配置文件本身的权限很敏感，比如PostgreSQL要求nf不能对group和其他用户可写，否则直接拒绝启动，这属于安全设计，别硬改回去。
第三种情况，磁盘满了或者inode耗尽。这个坑最坑人，因为服务启动时不一定立刻报磁盘错误，它可能先尝试写日志、写临时文件、创建共享内存段，一旦这些操作失败，整个启动流程就中止了。你df -h看磁盘还有20%剩余，觉得没问题？那得再看看df -i，inode用完了照样写不进文件。小文件特别多的目录，比如数据库的binlog或者undo log目录，最容易爆inode。处理办法也直接：清理过期日志、归档旧数据、删掉没用的临时文件。要是数据盘真满了，还得考虑扩容或者迁移，别硬撑。
再有一个，就是配置参数本身写错了。这里说的不是语法错误——语法错误启动时直接就报出来了，最怕的是那种“值不合法但语法没问题”的情况。比如MySQL的f里，innodbbufferpoolsize你写了个2G，但系统内存就1.5G，启动时分配失败。或者PostgreSQL的sharedbuffers设置超过了内核允许的共享内存上限。这时候启动日志里往往只有一句“FATAL: could not create shared memory segment”。排查方法：先用free -m看看实际可用内存，再对照配置逐项检查。还有个容易忽略的：字符集设置。你从Windows上改的配置文件，编码是GBK，拿到Linux上一读，中文注释全变乱码，某些解析器直接罢工。
说到日志，很多人启动失败后一脸懵，不知道去哪看原因。每个数据库都有自己的日志位置，MySQL在datadir目录下的hostname.err，PostgreSQL在pg_log目录或者stderr重定向的文件里，Redis在logfile配置指定的路径。但有个更快的排查动作：直接前台启动。比如MySQL用mysqld --console，PostgreSQL用postgres -D /var/lib/pgsql/data，Redis用redis-server /etc/nf --daemonize no。前台启动的好处是，所有报错直接刷在终端上，不用翻日志文件，而且可以配合debug级别输出，把SQL解析、事务恢复这些细节全打出来。等找到问题了，再改回后台启动。
硬件资源不够也是个硬伤，特别是内存和文件描述符。数据库启动时要初始化各种缓存、加载索引、预分配日志文件，服务器内存不够，或者ulimit -n设得太低，都会导致启动失败。你可能会遇到“Too many open files”这个报错，明明服务刚启动，哪来那么多文件句柄？其实是因为配置文件里指定了太多表、太多分区，或者开启了太多的后台线程。解决办法：调大/etc/security/nf里的nofile限制，或者优化配置，减少不必要的预加载。如果是云服务器，还得检查一下swap是不是被关了，有些数据库在swap不足时会直接拒绝启动。
说一个很多人忽略的：系统时间和时区问题。某些数据库，尤其是带证书认证或者token机制的，启动时会检查系统时间是否在有效期内。你服务器时间漂移了，或者时区设置不对，导致证书校验失败，服务起不来。排查方法：date -R看看当前时间和时区，再用openssl x509 -in server-cert.pem -noout -dates检查证书有效期。时间不准就同步一下，ntpdate或者chronyc，时区不对就timedatectl set-timezone。这个坑不常见，但一旦踩到，绝对让你怀疑人生。
你发现没有，这些原因没有一个是真正“难”的，全都在细节里。端口、权限、磁盘、配置、日志、资源、时间，就这七个维度，挨个过一遍，90%的启动失败都能解决。剩下的10%，要么是内核参数问题，要么是库文件损坏，那就得靠strace或者gdb去深挖了。但记住一个原则：别慌，别乱改，先看日志，再动手。数据库启动失败，从来不是玄学，只是你还没找到那个错了的标点符号。
