看到这个 故障分析 | MySQL OOM 故障应如何下手，想起来几天前也遇到一次MySQL服务因为OOM被杀掉的情况，记录一下
背景：
一个测试环境，由于Centos系统上没有设置虚拟内存，运行的MySQL实例buffer_pool_size配置的不合理，运行了一个较大的查询后，产生了一个戏剧性的问题。
现象：
前端工具执行某个sql，一点击执行，过几秒钟连接客户端显式断开MySQL连接，第一次没在意，以为是刚好遇到网络问题导致的。
因此又重新刷新连接，重新执行，然后又数据库连接又断开，于是又刷新连接，又执行又断开……，奇怪的是每次反复连接断开、连接断开、连接断开……
完全相同的现象反复几次之后，才意识到哪里好像的不对劲，难特么道谁在玩我？
感觉是不是MySQL服务被重启了，因为网络不可能总是在执行查询的时候出现故障，于是查看MySQL启动时间：
SELECT DATE_ADD(NOW(),INTERVAL -variable_value SECOND) AS startup_datetime FROM performance_schema.global_status WHERE variable_name = 'Uptime'
果不其然，从当时的时间点来看，刚刚启动了不到一分钟，看MySQL的errorlog，只是反复记录MySQL重启恢复，Starting crash recovery...，Crash recovery finished.
MySQL自身的errorlog中是看不到什么问题了，只能拉出来系统日志，MySQL的服务进程竟然是OOM后被系统杀掉了，然后才回头追溯各种配置，/var/log/message
后面其实还是有点疑惑，为什么没有吧这个OOM的信息记录到MySQL自己的error log中呢？mysql自己的error log也只记录了重启恢复的过程。
可能是，连MySQL自己都被杀掉了，谁来记这个日志呢。
不过好在是，mysqld进程被杀掉之后，一直在自动被唤醒，这下可以深刻地一直到mysql_safe进程的作用了，
教训
包括数据库和操作系统在内，一些基础配置还是要做好的，MySQL的配置可以自己把控，虚拟内存究竟多大，专业的事交给专业的人，也是一个专业问题。