缓存，读和写
如果有足够的内存，就完全可以避免磁盘读取请求。如果所有的数据文件都可以放在内存中，一旦服务器缓存“热”起来了，所有的读操作都会在缓存命中。虽然还是会有逻辑读取，不过物理读取就没有。但是写入是不同的问题。写入可以像读一样在内存中完成，但迟早要被写入到磁盘，所以它是需要持久化的。换句话说，缓存可以延缓写入，但不能消除写入。
写入从缓冲中大大受益，因为它把随机I/O更多地转换到连续I/O。异步（缓冲）写通常是由操作系统批量处理，使它们以更优化的方式刷新到磁盘。同步（无缓冲）写必须在写入到磁盘之后才能完成。这就是为什么它们受益于RAID控制器中电池供电的回写（Write-Bace）高速缓存。
选择固态存储
目前MySQL用户感兴趣的技术可以分为两大：SSD（固态硬盘）和PCIe卡。SSD通过实现SATA接口来模拟标准硬盘，所以可以替代硬盘驱动器，直接插入服务器中的现有插槽。PCIe卡使用特殊的操作系统驱动程序，把存储设置作为一个块设置输出。PCIe和SSD设备有时可以简单地都认为是SSD。
SSD模拟SATA硬盘驱动器。这是一个兼容性功能：替换SATA硬盘不需要任何特殊的驱动程序或接口。我们建议对SATA SSD硬盘使用RAID，单一驱动器的数据安全是无法让人信服的。
相对于SATA SSD，PCIe设备没有尝试模拟硬盘驱动器。这种设计是好事：服务器和硬盘驱动器之间的接口不能完全发挥闪存的性能。SAS/SATA互联带宽比PCIe要低，所以PCIe对高性能需求是更好的选择。PCIe设备延迟也低得多，因为它们在物理上更靠近CPU。没有什么比得上从PCIe设备获得的性能。缺点就是它们太贵了，差不多150元/G，而普通SSD才50/元G。
虽然有很多因素需要在闪存、硬盘和RAM之间权衡，在存储层次结构中，这些设备没有被当作一个整体处理。有时可以使用磁盘和内存技术的结合，这就是Flashcache。
Flashcache是一个Linux内核模块，使用Linux的设备映射器(Device Mapper)。它在内存和磁盘之间创建了一个中间层。这是Facebook开源和使用的技术之一，可以帮助其优化数据库负载。
Flashcache创建了一个块设备，并且可以被分区，也可以像其他块设备一样创建文件系统，特点是这个块设备是由闪存和磁盘共同支撑的。闪存设备用作读取和写入的智能高速缓存。
尽管Flashcace理论上可能更高效，但最终的性能表现并不如底层的闪存存储那么好，不过它仍然比磁盘快很多，所以还是值得考虑的方案。
应用使用Flashcache吗？如果你觉得不确定，最好得到专家的意见。归根到底，Flashcache是否合适是一个复杂的决定，涉及的因素很多。一般情况下，它似乎最适合以读为主的I/O密集型负载，并且工作集太大，用内存优化并不经济的情况。
优化SSD存储上的MySQL
增加InnoDB的I/O容量
调整innodb_io_capacity选项到更大的值。
让InnoDB日志文件更大
因为如果日志在磁盘上调的太大，崩溃恢复时需要随机I/O访问，会恢复很长时间。闪存让这个过程快很多，所以可以设置更大的日志文件。
把一些文件从闪存移到RAID
因为InnoDB日志是以512字节为单位的顺序I/O写下去，用闪存并不比RAID磁盘快。
禁用预读
配置InnoDB刷新算法
为闪存设备设置innodb_flush_neighbor_pages = 0。
禁用双写缓冲
限制插入缓冲大小
提醒一点，针对SSD上的很多功能和优化在标准版本的InnodDB中是无效的，只在Percona Server和XtraDB中适用。
RAID缓存
尽量关闭RAID的读或预读缓存，因为操作系统和数据库都有自己更大的缓存，RAID上的缓存是很小的，也是很珍惜的，尽量留给写缓存用。
写入缓存对同步写非常有用，例如事务日志和二进制日志，但是除非控制器有电池备份单元（BBU）或其他非易失性存储，否则不应该启用RAID缓存。
为了测试是否真的可以依赖RAID控制器的BBU，必须像实际情况一样切断电源一段时间，因为某些单元断电超过一段时间后就可能丢失数据。这里再次重申，任何一个环节出现问题都会使整个存储组件失效。
使用多磁盘券
MySQL创建了多种类型的文件：
数据和索引文件
事务日志文件
二进制日志文件
常规日志文件（例如，错误日志，查询日志和慢查询日志）
临时文件和临时表
InnoDB默认配置是将这些文件到放到一个目录的。然而，有时把这些文件分开放到多个卷可以帮助解决I/O负载高的问题。
建议针对一些大表或特殊功能表，将表文件放到单独的卷上，也可以使用分区表。
有的标准建议，就是把事务日志文件和数据文件放在不同卷上，这样日志的顺序I/O和数据的随机I/O不会相互影响。但是除非有很多硬盘（20或更多）或者闪存存储。
如果RAID控制器有BBU，分离事务日志与数据文件就没有必要了。因为即使有大量的事务日志写入，RAID缓存通常会合并I/O请求，通常只会得到每秒的物理顺序写请求。这通常不会干预数据文件的随机I/O，除非RAID控制器真的整体上饱和了。
如果有足够的内存，就完全可以避免磁盘读取请求。如果所有的数据文件都可以放在内存中，一旦服务器缓存“热”起来了，所有的读操作都会在缓存命中。虽然还是会有逻辑读取，不过物理读取就没有。但是写入是不同的问题。写入可以像读一样在内存中完成，但迟早要被写入到磁盘，所以它是需要持久化的。换句话说，缓存可以延缓写入，但不能消除写入。
写入从缓冲中大大受益，因为它把随机I/O更多地转换到连续I/O。异步（缓冲）写通常是由操作系统批量处理，使它们以更优化的方式刷新到磁盘。同步（无缓冲）写必须在写入到磁盘之后才能完成。这就是为什么它们受益于RAID控制器中电池供电的回写（Write-Bace）高速缓存。
选择固态存储
目前MySQL用户感兴趣的技术可以分为两大：SSD（固态硬盘）和PCIe卡。SSD通过实现SATA接口来模拟标准硬盘，所以可以替代硬盘驱动器，直接插入服务器中的现有插槽。PCIe卡使用特殊的操作系统驱动程序，把存储设置作为一个块设置输出。PCIe和SSD设备有时可以简单地都认为是SSD。
SSD模拟SATA硬盘驱动器。这是一个兼容性功能：替换SATA硬盘不需要任何特殊的驱动程序或接口。我们建议对SATA SSD硬盘使用RAID，单一驱动器的数据安全是无法让人信服的。
相对于SATA SSD，PCIe设备没有尝试模拟硬盘驱动器。这种设计是好事：服务器和硬盘驱动器之间的接口不能完全发挥闪存的性能。SAS/SATA互联带宽比PCIe要低，所以PCIe对高性能需求是更好的选择。PCIe设备延迟也低得多，因为它们在物理上更靠近CPU。没有什么比得上从PCIe设备获得的性能。缺点就是它们太贵了，差不多150元/G，而普通SSD才50/元G。
关于SSD在数据库方面的特性参见另一篇文章：http://blog.csdn.net/jiao_fuyou/article/details/16113067
虽然有很多因素需要在闪存、硬盘和RAM之间权衡，在存储层次结构中，这些设备没有被当作一个整体处理。有时可以使用磁盘和内存技术的结合，这就是Flashcache。
Flashcache是一个Linux内核模块，使用Linux的设备映射器(Device Mapper)。它在内存和磁盘之间创建了一个中间层。这是Facebook开源和使用的技术之一，可以帮助其优化数据库负载。
Flashcache创建了一个块设备，并且可以被分区，也可以像其他块设备一样创建文件系统，特点是这个块设备是由闪存和磁盘共同支撑的。闪存设备用作读取和写入的智能高速缓存。
尽管Flashcace理论上可能更高效，但最终的性能表现并不如底层的闪存存储那么好，不过它仍然比磁盘快很多，所以还是值得考虑的方案。
应用使用Flashcache吗？如果你觉得不确定，最好得到专家的意见。归根到底，Flashcache是否合适是一个复杂的决定，涉及的因素很多。一般情况下，它似乎最适合以读为主的I/O密集型负载，并且工作集太大，用内存优化并不经济的情况。
优化SSD存储上的MySQL
增加InnoDB的I/O容量
调整innodb_io_capacity选项到更大的值。
让InnoDB日志文件更大
因为如果日志在磁盘上调的太大，崩溃恢复时需要随机I/O访问，会恢复很长时间。闪存让这个过程快很多，所以可以设置更大的日志文件。
把一些文件从闪存移到RAID
因为InnoDB日志是以512字节为单位的顺序I/O写下去，用闪存并不比RAID磁盘快。
禁用预读
配置InnoDB刷新算法
为闪存设备设置innodb_flush_neighbor_pages = 0。
禁用双写缓冲
限制插入缓冲大小
提醒一点，针对SSD上的很多功能和优化在标准版本的InnodDB中是无效的，只在Percona Server和XtraDB中适用。
RAID缓存
尽量关闭RAID的读或预读缓存，因为操作系统和数据库都有自己更大的缓存，RAID上的缓存是很小的，也是很珍惜的，尽量留给写缓存用。
写入缓存对同步写非常有用，例如事务日志和二进制日志，但是除非控制器有电池备份单元（BBU）或其他非易失性存储，否则不应该启用RAID缓存。
为了测试是否真的可以依赖RAID控制器的BBU，必须像实际情况一样切断电源一段时间，因为某些单元断电超过一段时间后就可能丢失数据。这里再次重申，任何一个环节出现问题都会使整个存储组件失效。
使用多磁盘券
MySQL创建了多种类型的文件：
数据和索引文件
事务日志文件
二进制日志文件
常规日志文件（例如，错误日志，查询日志和慢查询日志）
临时文件和临时表
InnoDB默认配置是将这些文件到放到一个目录的。然而，有时把这些文件分开放到多个卷可以帮助解决I/O负载高的问题。
建议针对一些大表或特殊功能表，将表文件放到单独的卷上，也可以使用分区表。
有的标准建议，就是把事务日志文件和数据文件放在不同卷上，这样日志的顺序I/O和数据的随机I/O不会相互影响。但是除非有很多硬盘（20或更多）或者闪存存储。
如果RAID控制器有BBU，分离事务日志与数据文件就没有必要了。因为即使有大量的事务日志写入，RAID缓存通常会合并I/O请求，通常只会得到每秒的物理顺序写请求。这通常不会干预数据文件的随机I/O，除非RAID控制器真的整体上饱和了。
二进制日志文件与数据文件单独存放是个好主意，即使数据文件丢失，二进制日志可以保存下来用于恢复。但这种考虑不适合于InnoDB事务日志，因为没有数据文件，事务日志没有任何用处。
这方面的优化也可以参考：http://blog.csdn.net/jiao_fuyou/article/details/16113287
585
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
