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目录混用)