MySQL如何避免使用swap Linux有很多很好的內存、IO調度機制，但是並不會適用於所有場景。對於DBA來說Linux比較讓人頭疼的一個地方是，它不會因為MySQL很重要就避免將分配給MySQL的地址空間映射到swap上。對於頻繁進行讀寫操作的系統而言，數據看似在內存而實際上在磁盤是非常糟糕的，響應時間的增長很可能直接拖垮整個系統。這篇blog主要講講我們作為DBA，怎樣盡量避免MySQL慘遭swap的毒手。 首先我們要了解點基礎的東西，比如說為什麼會產生swap。假設我們的物理內存是16G，swap是4G。如果MySQL本身已經占用了12G物理內存，而同時其他程序或者系統模塊又需要6G內存，這時候操作系統就可能把MySQL所擁有的一部分地址空間映射到swap上去。 cp一個大文件，或用mysqldump導出一個很大的數據庫的時候，文件系統往往會向Linux申請大量的內存作為cache，一不小心就會導致L使用swap。這個情景比較常見，以下是最簡單的三個調整方法： 1、/proc/sys/vm/swappiness的內容改成0（臨時），/etc/sysctl.conf上添加vm.swappiness=0（永久） 這個參數決定了Linux是傾向於使用swap，還是傾向於釋放文件系統cache。在內存緊張的情況下，數值越低越傾向於釋放文件系統cache。 當然，這個參數只能減少使用swap的概率，並不能避免Linux使用swap。 2、修改MySQL的配置參數innodb_flush_method，開啟O_DIRECT模式。 這種情況下，InnoDB的buffer pool會直接繞過文件系統cache來訪問磁盤，但是redo log依舊會使用文件系統cache。值得注意的是，Redo log是覆寫模式的，即使使用了文件系統的cache，也不會占用太多。 3、添加MySQL的配置參數memlock 這個參數會強迫mysqld進程的地址空間一直被鎖定在物理內存上，對於os來說是非常霸道的一個要求。必須要用root帳號來啟動MySQL才能生效。 還有一個比較復雜的方法，指定MySQL使用大頁內存（Large Page）。Linux上的大頁內存是不會被換出物理內存的，和memlock有異曲同工之妙。
