看到這個 故障分析 | 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的配置可以自己把控，虛擬內存究竟多大，專業的事交給專業的人，也是一個專業問題。