Mysql服务器文件系统规划:
/dev/sda1 /boot
/dev/sda2 /
/dev/sda3 /home
/dev/sda4 /tmp
/dev/sdb1 /data
/dev/sdc1 /log
sda:系统目录 sdb:数据目录 sdc:日志目录
linux调度策略：
--查看当前的调度策略:
less /sys/block/sdb/queue/scheduler
[noop] anticipatory deadline cfq
--建议修改为deadline：
echo deadline> /sys/block/sdb/queue/scheduler
--查看当前的调度策略:
less /sys/block/sdc/queue/scheduler
[noop] anticipatory deadline cfq
--建议修改为deadline：
echo deadline> /sys/block/sdc/queue/scheduler
deadline的特点：
通过时间以及硬盘区域进行分类,这个分类和合并要求类似于noop的调度程序.
Deadline确保了在一个截止时间内服务请求,这个截止时间是可调整的,而默认读期限短于写期限.这样就防止了写操作因为不能被读取而饿死的现象.
Deadline对数据库环境(ORACLE RAC,MYSQL等)是最好的选择
日志选择配置篇
-- binlog日志（顺序写入）
内容:记录所有数据库变化的日志，，通过binlog可以实现主从同步，数据恢复等；binlog为两个层次的，必须支持Innodb_support_xa，写
完成以及binlog写入完成时，才会提交事务。
说明：Innodb_support_xa设置为1，标志支持分布式事务，主要保证binary log和其他引擎的主事务数据保持一致性，属于同步操作；如果设置为0，就是异步操作，这样就会一定程度上减少磁盘的刷新次数和磁盘的竞争。
-- error日志（写入的数据非常少）
错误日志包含四类信息：
(1) 服务器启动和关闭进程过程中的信息；
(2) 服务器运行过程中的错误信息；
(3) 事件调度器运行一个事件时产生的信息；
(4) 在从服务器上启动从服务器进程时产生的信息。
-- slow日志（跟业务相关，顺序写入）
内容：慢日志记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。
说明：主要跟业务相关，如果业务系统不完善，long_query_time又相对较小的话，那么slow_log日志将会非常的大，这是就要考虑顺序写入的状况。
--tmp目录（顺序写入）
内容：tmp目录要求的性能会更高，建议使用tmpfs，如果系统的临时目录写入频繁，读写的请求也相对较高，放系统的tmp目录下是一个很好的选择，并且tmp目录的空间要求不大，要是查询量非常大，数据集也非常大，整个tmp目录都不一定存放的下，可以选择单独的划分盘，
--InnoDb_log_file（顺序循环写入）
内容：事务日志或称redo日志，开启几组日志来服务于当前mysql数据库,mysql采用顺序，循环写方式，每开启一个事务时，会把一些相关信息记录事务日志中(记录对数据文件数据修改的物理位置或叫做偏移量);
说明：可通过 innodb_log_file_size调节大写，事务日志的大小也会影响性能，可将事务日志单独分盘。
--double_write（顺序读写）
内容：为了解决 partial page
write 问题 ，当mysql将脏数据flush到data file的时候, 先使用memcopy 将脏数据复制到内存中的double
write buffer ，之后通过double write
buffer再分2次，每次写入1MB到共享表空间，然后马上调用fsync函数，同步到磁盘上，避免缓冲带来的问题，在这个过程中，doublewrite是顺序写，开销并不大，在完成doublewrite写入后，在将double
write buffer写入各表空间文件，这时是离散写入。
如果发生了极端情况（断电），InnoDB再次启动后，发现了一个Page数据已经损坏，那么此时就可以从doublewrite buffer中进行数据恢复了。
建议方案：
-- binlog日志文件、error日志文件、show日志文件存储在/log日志目录中
-- tmp文件制定为系统根目录/tmp
-- 其他所有目录指定为数据目录/data(与data目录混用)