目前，資料庫公認的最快的IO方式是讀寫裸裝置，ORACLE資料庫一般配置，日誌和資料全部存放到裸裝置上。

MYSQL目前支援資料存放到裸裝置，本身不支援日誌檔案的裸裝置，但是隻需要簡單的步驟就可以實現全裸裝置，如下：

初次使用裸裝置要先初始化:

sudo service mysql stop;

sudo nano /etc/mysql/my.cfg 

//修改my.cfg的內容innodb_data_file_path=raw1:1837455Mnewraw, 其中配置資料的大小一定要比空間的實際大小少1M，以便存放資料塊結束標誌

//其中newraw表示將初始化raw裝置。

// 修改innodb_log_file_size=16G, 其中配置資料的大小等於日誌檔案或者分割槽的大小

sudo rm /var/lib/mysql/ib_data1  //  刪除預設資料檔案

sudo ls -l /dev/bcache0  // 顯示裸裝置節點號， 這裡是使用了帶bcache的硬碟分割槽，使用者應根據自己的實際選擇

sudo mknod /var/lib/mysql/ib_data1 b 251 0

sudo chown mysql:mysql /var/lib/mysql/ib_data1

sudo chmod 660 /var/lib/mysql/ib_data1

sudo cat /var/log/mysql/error.log  // 顯示資料，觀察初始化進行情況，直到執行完畢

// 將初始化/var/lib/mysql/ib_data1對應的分割槽，並且生成  /var/lib/mysql/ib_logfile0，  /var/lib/mysql/ib_logfile1 這2個檔案

sudo service mysql stop;

sudo nano /etc/mysql/my.cfg

//修改my.cfg的內容innodb_file_path=raw1:1837455Mraw,

MYSQL本身不支援日誌檔案的裸裝置，

但是通過linux命令mknod指定硬連結後，就可以支援裸裝置，將提供最高的IO效能,  具體的方法就是：

分一個與日誌檔案同樣大小的分割槽, 然後用dd拷貝日誌檔案內容， 通過linux命令mknod指定硬連結後，就可以支援裸裝置

sudo dd if=/var/lib/mysql/ib_logfile0 of=/dev/md1p2 bs=1M;  // 拷貝日誌檔案到分割槽

sudo dd if=/var/lib/mysql/ib_logfile1 of=/dev/md1p3 bs=1M;

ls  -l /dev/md1p2;   // 顯示裝置的節點號，後面mknod用

sudo rm /var/lib/mysql/ib_logfile0; //  刪除日誌檔案

sudo rm /var/lib/mysql/ib_logfile1;

sudo mknod /var/lib/mysql/ib_logfile0 b 259 1;   // 做裸裝置分割槽的硬連結，把分割槽內容作為檔案的內容

sudo mknod /var/lib/mysql/ib_logfile1 b 259 2;

sudo chown mysql:mysql /var/lib/mysql/ib_logfile0

sudo chown mysql:mysql /var/lib/mysql/ib_logfile1

sudo chmod 660 /var/lib/mysql/ib_logfile0

sudo chmod 660 /var/lib/mysql/ib_logfile1

sudo service mysql start;

sudo cat /var/log/mysql/error.log  // 顯示資料，觀察資料庫系統啟動情況，將發現系統完全正常。

這樣就實現了日誌裸裝置+資料裸裝置的高效能IO配置, 比檔案方式快很多。

我目前的MYSQL資料庫linux系統，習慣上分割槽方式，一個/根分割槽，分配SSD1的12G, 1個backup分割槽做系統的備份，分配SSD2的12G, 2塊SSD剩餘的幾百兆空間做soft raid1，做硬碟磁碟陣列的ssd cache,  使用的軟體是bcache或者flahcache。

bcache不支援LVM2分割槽加速，支援soft RAID，bcache安裝使用中遇到的問題比較多，預設的引數比較保守，仔細規劃使用後，繞過幾個挖坑的故障點，是基本可用的，雖然bcache目前的使用者不多，由於效能突出，未來的前景本人更看好。

bcache目前只做一個cache主資料分割槽，使用中發現如果多個cache，每次啟動每個cache名稱對應的物理裝置會隨機變化，為了繞過這個坑，只做一個cache或者使用UUID目錄，也可以解決這個問題。

bcache以桶的方式分配空間，一般要求設定桶大小為擦除塊的大小，目前最新intel SSD儲存晶片的擦除塊是8M（16KB*512), bcache只能支援到4M,  超過4M的引數將出錯。我只好先用4M的桶對付著用。

bcache雖然支援指定資料塊的大小，預設是512位元組，但是實際測試發現指定資料庫的16Kbyte，內部還是會出錯的，因此，就採用預設的512位元組吧，這樣就又繞過一個坑。

bcache有大量的引數，比flashcache要多很多，並且引數的預設引數比較保守，優化中修改的數量比較大，並且修改後重新啟動，下次需要重新設定，為了方便，將修改命令全部放到啟動sh中，保證下次啟動引數重新載入。

bcache也支援write back, 但是引數當中，預設啟動擁塞控制，最好關閉；否則，將可能在大併發下切換為write through方式。

bcache的部分引數，雖然能夠修改，但是隨時被bcache自動修改，例如：write_back的後臺回寫量。

bcache總體比較複雜，效能比較高，但是各類資料稀少，並且存在一些明顯的BUG,  使用中需要注意， 今後我將單獨寫一篇部落格具體寫bcache的優化。

flashcache比較可靠，目前很多重量級使用者都在使用，例如阿里巴巴等，幾乎不會遇到什麼問題，並且支援LVM2分割槽的加速，flashcache效能不夠好，對SSD的磨損大。

一個RAID1+0磁碟陣列分出一個/var分割槽，大小是36G，用於存放資料(本人的習慣是分配為記憶體大小+4G)，其餘空間分為3個裸分割槽，分別為16G(本人的習慣是分配為記憶體大小一半），16G,  其餘全部空間做資料的裸裝置。2個16G的分割槽是MYSQL的日誌檔案ib_logfile0與ib_logfile1的裸裝置，最後一個分割槽是ib_data1的裸裝置。

目前 ubuntu系統已經內建了 bcache和flashcache,  這足以說明SSD cache是大勢所趨， 使用將越來越廣泛。

ubuntu下的安裝命令是：

flashcache  :       sudo apt-get install flashcache-utils;

bcache :              sudo apt-get install bcache-tools;