MySQL innodb_buffer_pool是在mysqld啓動時分配？操作系統如何顯示
查看my.cnf中配置：innodb_buffer_pool_size = 20G，物理機實際內存32G
mysqld啓動前後內存使用對比：
啓動mysql 後，used增加了1.5G，cached增加2M
top查看mysqld進程
VIRT：
1.進程“需要的”內存大小，包括進程使用的庫、代碼、數據，以及malloc、new分配的堆空間和分配的棧空間等；
2. mysqld申請22.3G的內存，但實際只使用了1.5G，那麼virt它會增長22.3G，而不是實際的1.5G使用量。
3. MySQL啓動時實際只是在虛擬內存中分配了地址空間，而並沒有真正的映射到物理內存上。
4.VIRT =SWAP + RES
Linux malloc內存分配:
1.malloc分配內存是先在虛擬內存中分配地址的，到實際使用時才真正的映射到物理內存
2. 到了MySQL真正要映射物理內存時，首先分配物理內存，此時top的res增加
3.如果物理內存不夠用了，分配swap，此時性能很差，此時top的res增加
所以，如果由於機器內存使用不當，到了MySQL真正要映射物理內存時，如果物理內存（內存+swap）不足了，就會出錯甚至退出。
結論：innodb_buffer_pool_size= 20G再mysqld啓動時在虛擬內存中分配地址，在使用過程中再映射到物理內存,如果物理內存（內存+swap）不足了，就會出錯甚至退出。
篇外：Linux下的OOM Killer：
假如一個程序A已經運行，並且分配了22G內存（機器配置是物理內存16G+SWAP 8G），但是沒有真正的映射到物理內存；
這時MySQL啓動，innodb_buffer_pool_size=8G，啓動正常；
然後程序A開始實際分配物理內存，一下子只剩下2GSWAP內存了；
這時MYSQL也開始實際使用內存，因爲只有2GSWAP，所以性能很差，再超過2G時，內存耗盡，這時OOMKiller開始殺進程，怎麼殺呢，誰佔用內存多殺誰，於是將進程A殺掉了，內存一下子回來了，MySQL不會退出；
但是一般系統中MySQL都是分配內存最大的，所以經常性的是MySQL被殺掉。