主机环境

OS：CentOS6.8

OS内存：7G

MySQL版本：5.7.22

innodb_buffer_pool：6G

---

最近发现MySQL测试库在每天下午5点左右会莫名崩溃，排查问题发现崩溃时间前后有一个定时任务在执行，这个定时任务会在每天下午4点半执行逻辑导入；将定时任务改到凌晨执行后，第二天早晨上班发现数据库又崩了。

由于error.log不会有任何有用的报错信息，因此这次结合系统日志/var/log/messages来进行问题的复现

开始执行逻辑导入

mysql -uroot -p"密码" xxxxx < /data/wp/xxxxx.2018-09-27.sql

打开top可以看到在几分钟之后，mysqld进程的内存使用率开始飙升，最终突破91%后mysqld进程消失在top显示列表中

导入界面显示已经与MySQL服务失去连接

从系统日志来看，这就是因为逻辑导入引起的oom事件（系统日志显示如下）

由于我是没设置swap的，如果有swap的话，或许能撑一下

---

参考网上的方法，一共进行了2种尝试

第一种是在导入语句中加入参数-q，据说可以不产生缓存

mysql -uroot -p"密码" -q xxxxx < /data/wp/xxxxx.2018-09-27.sql

然而经过测试，该方法并没有什么卵用

第二种方法是在修改innodb_open_files这个参数

在配置文件中，这个参数我设置的是65535，实际使用只有几百

在cnf配置文件中将该参数由65535调整为2048，之后重启mysql发现初始占用内存的确有不小的改观，从31%下降到12%

然而在多次的导入之后，仍然发生了oom报错

此外open_files这个参数不宜设置得过小

---

最终的解决方案是调整了innodb_buffer_pool，毕竟对于总内存仅有7G的OS来说将mysql的内存设置到6G实在是有点太大了；这是此次oom事件的深层次原因

而直接的导火索就是此次的逻辑导入，该库日常的使用也就是不到3G的样子而已