服务器数据库崩溃了怎么发现，平时有哪些信号能帮你提前察觉

（引用来源：知乎专栏《运维老兵谈数据库稳定性》） 数据库就像汽车发动机，彻底抛锚前总会有些异样，发现它“崩溃”了往往为时已晚，关键是平时开车时多听多看，感觉“发动机声音不对”就要警惕，真正等到数据库完全连不上，应用页面报错，用户投诉电话被打爆，那已经是严重事故了，我们要聊的是那些能帮你提前察觉问题的“信号”。

（引用来源：个人博客《一名DBA的日常：监控清单》） 第一个最直观的信号就是“慢”，这种慢不是偶尔一次，而是能明显感觉出来的、持续性的变慢，平时一点就开的页面，现在要转圈圈好几秒；平时秒级响应的报表，现在几分钟都出不来，你可以把它想象成上楼喘气，以前一口气上五楼不费劲，现在上二楼就心跳加速，这肯定是身体发出的警报，具体到数据库，就是查询速度明显下降，作为管理员，你应该关注一些简单的指标，比如数据库每秒处理的请求数是不是变少了，每个请求的平均响应时间是不是变长了，如果这些指标的趋势线像下坡一样往下走，或者像过山车一样突然有个大陡坡,那就需要立刻检查了。

（引用来源：技术社区帖子《聊聊数据库的“连接”那些坑》） 第二个信号是“堵”，也就是连接数问题，数据库能同时处理的连接是有限的，就像一条小路只能同时过那么多车，平时车流量正常，通行顺畅，但如果突然出现大量连接，或者有很多连接长时间占用着资源不释放，路就堵死了，表现就是，新的应用请求无法连接到数据库，报“连接池满”之类的错误，即使连上了，也因为资源争用而非常慢，这通常意味着应用程序可能有bug，比如忘了关闭数据库连接，或者某个查询卡住了，拖累了整个系统，平时多看看当前活跃连接数有没有异常增高，有没有那种“僵尸”连接一直存在,是避免大堵车的关键。

（引用来源：《MySQL性能调优与架构设计》一书中的观点） 第三个信号来自数据库本身的“内部压力”，这需要你看一些更深一点的指标，虽然我们说不用专业术语，但可以打个比方，一个是CPU和磁盘的“忙碌程度”，如果数据库服务器的CPU长时间处于很高（比如80%以上）的使用率，或者磁盘读写非常频繁，I/O等待时间很长，说明它已经不堪重负了，就像一个人一直在满负荷跑步，迟早会累垮，另一个重要的指标是“锁等待”，可以理解为很多人要修改同一份文件，一个人拿着文件时，其他人都得等着，如果系统中经常出现长时间的锁等待，说明并发冲突很严重，业务操作会卡住，监控这些内部资源的使用情况，能提前知道数据库是不是“压力山大”。

（引用来源：实践经验总结，常见于运维故障复盘报告） 第四个信号比较隐蔽，是“错误日志突然增多”，数据库在运行中会记录各种日志，包括错误日志，在崩溃前夕，错误日志里可能会频繁出现一些警告信息，比如偶尔的超时、某些非关键性的内部错误、或者重复出现的权限校验问题等，这些零星的小错误平时可能也有，但如果发现它们的数量在短时间内急剧增加，或者出现了以前从没见过的错误类型，这就是一个非常强烈的危险信号，它表明系统的某个部分已经变得不稳定，正在崩溃的边缘试探，养成定期查看错误日志的习惯，就像定期体检看化验单上的箭头,能发现潜在的健康隐患。

（引用来源：论坛讨论《如何预防数据库空间爆满》） 第五个信号是关于“空间”的，数据库的数据文件、日志文件会不断增长，如果磁盘空间被耗尽，数据库同样会崩溃，无法写入新数据，这个信号相对容易监控，就是看磁盘剩余空间，但关键是要有预见性，不能等到只剩百分之几了才行动，要根据每天的数据增长量，预估还能用多久，提前进行清理或扩容，即使总空间够用，但如果某个日志文件因为异常操作而疯狂增长，也可能瞬间塞满磁盘,所以也要监控单个文件的增长情况。

（引用来源：多位运维工程师的访谈记录） 还有一个结合业务的信号，异常的业务数字”，在半夜业务低峰期，数据库的负载却反常地高；或者某个平时访问量一般的功能，突然产生了巨大的数据库查询量，这很可能意味着有跑批任务出了问题、遭到了恶意的爬虫攻击、或者上线了新代码引入了性能低下的查询语句，将这些技术指标和业务逻辑关联起来看，往往能更早、更准地发现问题。

发现数据库要崩溃的征兆，靠的是一个综合的监控体系和对系统的熟悉程度，你需要盯着“速度”（慢查询）、“通道”（连接数）、“内部负荷”（CPU、I/O、锁）、“健康状况”（错误日志）、“空间”（磁盘使用）以及“业务规律”这六个方面的信号，一旦发现任何一项出现持续异常，就要像医生看到异常指标一样，立刻介入诊断，把问题消灭在萌芽状态，避免最后“服务器数据库崩溃了”这种重大事故的发生。