前面兩章，我們分析了Linux記憶體分配的策略以及Linux透過使用OOM_Killer的機制解決了「超售」引起的風險，MySQL同其他的應用程式一樣，在作業系統允許的範圍內也是可以超售的，一般人理解，Innodb_buffer_pool必須小於實際物理內存，否則MySQL會啟動失敗。其實這是一個誤區，這個不是MySQL層控制的，這個是作業系統（OS）層控制的，就是前面提到的/proc/sys/overcommit_memory控制OS是否允許「超售」。如果允許“超售”，則Innodb_buffer_pool可以遠遠超過實際的記憶體空間大小，但是這部分空間是沒有使用的。我們可以做個小實驗，見下圖：
MySQL的Innodb_buffer_pool開了5G，但實際記憶體只有3G。
講了這麼多，現在言歸正傳，回到我們最早提到的RDS實例被OS Kill掉的問題上來，前面我們也提到了，一旦實例可用內存不足，MySQL一般都會成為OOM_Killer的首選目標。這裡就牽涉到兩個問題：
1.為什麼會記憶體不足？
2.如何讓MySQL擺脫被Kill的厄運？
首先我們來看第一個問題。記憶體不足這個問題產生原因很多，但是主要就兩個方面，第一個是MySQL自身記憶體的規劃有問題。第二個是一般部署MySQL的伺服器，都會部署很多的監控或定時任務腳本，而這些腳本往往缺少必要的記憶體限制，導致在高峰期的時候佔用大量的內存，導致觸發Linux OOM_Killer機制，MySQL就無辜犧牲了。
那要如何才能讓MySQL擺脫被Kill的厄運呢？ MySQL被Kill的根源在於Linux超售的記憶體分配機制，前面也提到了，只要有這種超售的機制，就不可能完全避免某一個應用程式被Kill的風險。那要讓MySQL一定不會被Kill掉，只能禁止作業系統超出實際記憶體空間的分配記憶體。但前面我們也提過，對於部署了MySQL的伺服器，我們不建議這麼做，因為MySQL的許多記憶體都是剛開始申請了，並不是立即使用的，OS一旦禁止超售，這不僅對MySQL自身內存規劃提出更苛刻的要求，同時也存在記憶體無法充分利用的問題。同時，MySQL的每個連接的私有記憶體是動態分配的，如果分配不到，就會直接導致伺服器Crash，這樣也會增加MySQL Crash的風險。
既然受限於作業系統，無法完全做到避免被Kill，那隻能盡量降低MySQL被Kill的幾率。我覺得至少可以做下面3件事：
1)合理的規劃MySQL的記憶體使用。
2)調整OOM_adj參數，將MySQL被OOM_Killer鎖定的優先權降低。
3)加強記憶體的監控和警報，一旦警報，DBA應該迅速介入，Kill掉一些佔用較多記憶體的連線。
