搞服务器的人，最烦的就是那种反反复复的毛病：MySQL数据库隔三差五崩一次，崩完重启又好了，好了没几天又崩，搞得人身心俱疲。每次问别人咋回事，得到的答案都是先重启再说，可重启只是治标，下次该崩还崩。其实吧，MySQL崩溃从来不是无缘无故的，它的错误日志里都写着呢，只是很多人从来没去看过。今天就把MySQL日志怎么看、崩溃的常见原因有哪些，一次给你讲清楚。
先找到日志在哪，这是第一步
MySQL的错误日志是排查崩溃的第一手资料。不同系统的日志位置不一样：CentOS上常见的是/var/log/mysql/error.log或者/var/log/mysqld.log，Debian系一般在/var/log/mysql/error.log。找不到也没关系，登录MySQL执行SHOW VARIABLES LIKE ‘log_error’，它会直接告诉你日志文件的路径，照方抓药就行。还有一种情况是日志被系统日志接管了，那就去/var/log/messages或者journalctl里翻MySQL相关的记录。
日志里最常见的三类崩溃原因
打开日志，翻到崩溃前最后那几行，原因基本就浮出水面了。第一类最常见：内存不足被系统杀掉。日志里会出现Out of memory或者直接被kill的字样，配合系统日志里的OOM记录就能确认。这种崩溃多发在内存紧张的小服务器上，MySQL吃内存吃得凶，加上PHP、Redis一起跑，内存一不够，系统第一个杀的就是它。第二类是磁盘写满，日志里会报磁盘空间不足、无法写入的错，数据库写不进去，自然就崩了。第三类是表损坏或者InnoDB的问题，日志里会有corruption、innodb相关的报错，这种相对少见但更麻烦。
内存被杀，怎么治本
如果是内存不足导致的崩溃，先别急着加内存，先看看是不是配置惹的祸。MySQL的innodb_buffer_pool_size是吃内存的大户，很多教程教人往大了调，结果小机器上把缓冲池调太大，别的程序没内存用，系统就开始杀进程。合理做法是算一算：机器总内存减去系统和其他程序需要的，剩下的再分给MySQL，别贪心。真不够用再加内存，加内存也是性价比最高的升级，比优化来优化去痛快多了。
磁盘满了和表损坏，分别咋处理
磁盘满导致的崩溃最好处理：清理空间，腾出余量，数据库一般就恢复正常了。平时注意给数据盘留足空间，把日志、备份放到单独的分区或者对象存储，别让它们把数据盘塞爆。表损坏的情况，如果日志明确指了哪张表，可以用MySQL自带的修复命令试试；InnoDB的表一般比较皮实，真损坏多半是硬件问题，比如磁盘坏道，那就得先换硬件再谈修复。硬件层面的问题，光靠软件救是救不回来的。
崩溃之后的善后与预防
数据库崩完，重启之前先做两件事：一是把错误日志里关键的那几行复制存档，方便下次对比，也方便求助别人的时候说得清楚；二是确认数据没丢、表没损坏，该做的修复做了再启动。预防方面，除了前面说的内存、磁盘管理，建议把MySQL的监控接上：内存、磁盘、连接数、慢查询都看着点，指标异常提前处理，别等数据库崩了才后知后觉。数据库这种核心组件，预防的性价比永远高于救火。
实在搞不定，求助前先备好料
要是日志看了半天还是云里雾里，想找别人帮忙或者问社区，一定先把料备足：MySQL版本、操作系统版本、崩溃前日志的最后几十行、系统日志里OOM相关的记录、当时的内存磁盘状况。把这些整理好再提问，别人一眼就能看出问题，比你说一句我的数据库老崩强一百倍。这行当里，会提问也是一种本事，问得清楚，答案来得才快。数据库是网站的心脏，心脏出问题不能只靠电击复苏，找到病因才是正经事。把日志当朋友，勤看着点，它能帮你省下无数个提心吊胆的夜晚。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
