前面兩章，我們分析了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掉一些占用較多內存的連接。
