目前，数据库公认的最快的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 service mysql start; // 开始初始化裸设备数据块，以及日志数据文件
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用
ls -l /dev/md1p3;
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;
以上，总结了一下， MYSQL的服务器高性能IO的分区方式，希望能够给大家帮助。
