日志文件：高性能MySQL：使用多磁盘卷

　　我们迟早都会碰到文件应该放哪的问题，因为MySQL创建了多种类型的文件:

　　（1）数据和索引文件

　　（2）事务日志文件

　　（3）二进制日志文件

　　（4）常规日志(例如，错误日志、查询日志和慢查询日志)

　　（5）临时文件和临时表

　　MySQL没有提供复杂的空间管理功能。默认情况下，只是简单地把每个Schema的文件放入一个单独的目录。有少量选项来控制数据文件放哪。例如，可以指定MyISAM表的索引位置，也可以使用MySQL 5.1的分区表。

　　如果正在使用InnoDB默认配置，所有的数据和文件都放在一-组数据文件 (共享表空间)中，只有表定义文件放在数据目录。因此，大部分用户把所有的数据和文件放在了单独的卷。

　　然而，有时使用多个卷可以帮助解决I/O负载高的问题。例如，一个批处理作业需要写人很多数据到一张巨大的表，将这张表放在单独的卷上，可以避免其他查询的I/0受到影响。理想的情况下，应该分析不同数据的I/O访问类型，才能把数据放在适当的位置，但这很难做到，除非已经把数据放在不同的卷上。

　　你可能已经听过标准建议，就是把事务日志和数据文件放在不同的卷上面，这样日志的顺序I/O和数据的随机I/O不会互相影响。但是除非有很多硬盘(20或更多)或者闪存存储，否则在这样做之前应该考虑清楚代价。

　　二进制日志和数据文件分离的真正的优势，是减少事故中同时丢失数据和日志文件的可能性。如果RAID控制器上没有电池支持的写缓存，把它们分开是很好的做法。

　　但是，如果有备用电池单元，分离卷就可能不是想象中那么必要了。性能差异很小是主要原因。这是因为即使有大量的事务日志写人，其中大部分写入都很小。因此，RAID缓存通常会合并I/O请求，通常只会得到每秒的物理顺序写请求。这通常不会干预数据文件的随机I/O,除非RAID控制器真的整体上饱和了。一般的日志，其中有连续的异步写人、负荷也低，可以较好地与数据分享一个卷。

　　将日志放在独立的卷是否可以提升性能?通常情况下是的，但是从成本的角度来看这个问题，是否真的值得这么做，答案往往是否定的，尽管很多人不这么认为。

　　原因是:为事务日志提供专门的硬盘是很昂贵的。假设有六个硬盘驱动器，最常规的做法是把所有六块盘放到一个 RAID卷，或者分成两部分，四个放数据，两个放事务日志。不过如果这样做，就减少了三分之一-的硬盘放数据文件,这会导致性能显著地下降。此外，专门提供两个驱动器，对负载的影响也微不足道(假设RAID控制器有电池支持的写缓存)。

　　另一方面，如果有很多硬盘，投入一一些给事务日志可能会从中受益。例如，一共有30块硬盘，可以分两块硬盘(配置为一个RAID 1的卷)给日志，能让日志写尽可能快。对于额外的性能，也可以在RAID控制器中分配一些写级存空间给这个RAID卷。

　　成本效益不是唯一考虑的因素。可能想保持InnoDB的数据和事务日志在同一个卷的另一个原因是，这种策略可以使用LVM快照做无锁的备份。某些文件系统允许-致的多卷快照，并且对这些文件系统，这是个很轻量的操作，但对于ext3有很多东西需要注意。(也可以使用Percona XtraBackup来做无锁备份)

　　如果已经启用sync_ binlog,二进制日志在性能方面与事务日志相似了。然而，二进制日志存储跟数据放在不同的卷，实际上是一一个好主意一把它们分开存放更安全， 因此即使数据丢失，二进制日志也可以保存下来。这样，可以使用二进制日志做基于时间点的恢复。这方面的考虑并不适用于InnoDB的事务日志，因为没有数据文件，它们就没用了，你不能将事务日志应用到昨晚的备份。(事务日志和二进制日志之间的区别在其他数据库的DBA看来，很难搞明白，在其他数据库这就是同一个东西。)

　　另外一个常见的场景是分离出临时目录的文件，MySQL做filesorts (文件排序)和使用磁盘临时表时会写到临时目录。如果这些文件不会太大的话，最好把它们放在临时内存文件系统，如tmpfs。这是速度最快的选择。如果在你的系统上这不可行，就把它们放在操作系统盘上。典型的磁盘布局是有操作系统盘、交换分区和二进制日志的盘，它们放在RAID1卷上。还要有一个单独的RAID5或RAID 10卷，放其他的一切东西。