如果在闪存上运行MySQL,有一些配置参数可以提供更好的性能。InnoDB 的默认配置从实践来看是为硬盘驱动器定制的，而不是为固态硬盘定制的。不是所有版本的InnoDB都提供同样等级的可配置性。尤其是很多为提升闪存性能设计的参数首先出现在PerconaServer中，尽管这些参数很多已经在Oracle版本的InoDB中实现，或者计划在未来的版本中实现。
改进包括:
增加InnoDB的1/O容量
闪存比机械硬盘支持更高的并发量，所以可以增加读写I/O线程数到10或15来获得更好的结果。也可以在2000 ~ 20 000范围内调整imodb io capacity选项，这要看设备实际上能支撑多大的IOPS.尤共是对Oraele官方的ImoDB这个很有必要，内部有更多算法依赖于这个设置。
让InnoDB日志文件更大
即使最近版本的InnoDB中改进了崩溃恢复算法，也不应该把磁盘上的日志文件调得太大，因为崩溃恢复时需要随机1/0访问，会导致恢复需要很长一段时间。闪存存储让这个过程快很多，所以可以设r更大的InnoDB日志文件，以帮助提升和稳定性能。对于Oracle官方的InnoDB,这个设置尤其重要，它维持一“ 个持续的脏页刷新比例有点麻烦，除非有相当大的日志文件——4GB 或者更大的日志文件，在写的时候对服务器来说是个不错的选择。Percona Server 和MySQL 5.6支持大于4GB的日志文件。
把一些文件从闪存转移到RAID
除了把InnoDB日志文件设置得更大，把日志文件从数据文件中拿出来，单独放在一个带有电池保护写缓存的RAID组上而不是固态设备上，也是个好主意。这么做有几个原因。一个原因是日志文件的1/O类型，在闪存设备上不比在这样一个RAID组上要快。InnoDB写日志是以512字节为单位的顺序I/O写下去，并且除了崩溃恢复会顺序读取，其他时候绝不会去读。这样的I/0操作类型用闪存设备是很浪费的。并且把小的写人操作从闪存转移到RAID卷也是个好主意，因为很小的写人会增加闪存设备的写放大因子，会影响-些设备的使用寿命。大小写操作混合到一起也会引起某些设备延时的增加。基于相同的原因，有时把二进制日志文件转移到RAID卷也会有好处。并且你可能会认为ibdatal文件也适合放在RAID卷上，因为ibdatal文件包含双写缓冲(Doublewrite Buffer)和插人缓冲(Insert Buffer)，尤共是双写缓冲会进行很多重复写人。在Percona Server 中，可以把双写缓冲从ibdatal文件中拿出来，单独存放到一个文件，然后把这个文件放在RAID卷上。
还有另一个选择:可以利用Percona Server 的特性，使用4KB的块写事务日志，而不是512字节。因为这会匹配大部分闪存本身的块大小，所以可以获得更好的效果。所有的上述建议是对特定硬件而言的，实际操作的时候可能会有所不同，所以在大规模改动存储布局之前要确保已经理解相关的因素一并辅以适当的测试。
禁用预读
预读通过通知和预测读取模式来优化设备的访问，一旦认为某些数据在未来需要被访问到，就会从设备上读取这些数据。实际上在InnoDB中有两种类型的预读，我们发现在多种情况下的性能问题，其实都是预读以及它的内部工作方式造成的。在许多情况下开销比收益大，尤其是在闪存存储，但我们没有确凿的证据或指导，禁用预读究竟可以提高多少性能。
在MySQL 5.1的InnoDB Plugin中，MySQL禁用了所谓的“随机预读”，然后在MySQL 5.5又重新启用了它，可以在配置文件用一个参数配置。Percona Server 能让你在旧版本里也一样可以配置为random (随机)或linear_read_ahead (线性预读)。
配置InnoDB刷新算法
这决定InnoDB什么时候、刷新多少、刷新哪些页面，这是个非常复杂的主题，这里我们没有足够的篇幅来讨论这些具体的细节。这也是个研究比较活跃的主题，井且实际上在不同版本的InoDB和MySQL中有多种有效的算法。
标准InoDB算法没有为闪存存储提供多少可配置性，但是如果用的是Percona_XraDB (包含在Percoa Sever和MariaDB中)，我们建议设置innodb adaptive_checkpoint选项为keep average,不要用默认值estimate.这可以确保更持续的性能，并且避免服务器抖动，因为estinate算法会在闪存存储上引起抖动。我们专门为闪存存储开发了keep average,因为我们意识到对于闪存设备，把希望操作的大量I/O推到设备上，并不会引起瓶颈或发生抖动。
另外，建议为闪存设备设置innodb flush neighbor. pages = 0.这样可以避免InnoDB尝试查找相邻的脏页-起刷写。 这个算法可能会导致更大块的写、更高的延迟，以及内部竞争。在闪存存储上这完全没必要，也不会有什么收益，因为相邻的页面单独刷新不会冲击性能。
禁用双写缓冲的可能
相对于把双写缓存转移到闪存设备，可以考虑直接关闭它。有些厂商声称他们的设备支持16KB的原子写人，使得双写缓冲成为多余的。如果需要确保整个存储系统被配置得可以支持16KB的原子写人，通常需要0 DIRECT和XFS文件系统。没有确凿的证据表明原子操作的说法是真实的，但由于闪存存储的工作方式，我们相信写数据文件发生页面写-部分的情况是大大减少的，并且这个收益在闪存设备上比在传统磁盘上要高得多，禁用双写缓冲在闪存存储上可以提高MySQL整体性能差不多50%，尽管我们不知道这是不是100%安全的，但是你可以考虑下这么做。
限制插入缓冲大小
插人缓冲(在新版InnoDB中称为变更缓冲(Change Buffer))设计来用于减少当更新行时不在内存中的非唯一索引引起的随机 I/O。在硬盘驱动器上，减少随机I/O可以带来巨大的性能提升。对某些类型的工作负载，当工作集比内存大很多时，差异可能达到近两个数量级。插人缓冲在这类场景下就很有用。
然而，对闪存就没有必要了。闪存上随机I/0非常快，所以即使完全禁用插入缓冲，也不会带来太大影响，尽管如此，可能你也不想完全禁用插入缓存。所以最好还是启用，因为1/0只是修改不在内存中的索引页面的开销的一部分。对闪存设备而言，最重要的配置是控制最大允许的插人缓冲大小，可以限制为一个相对比较小的值，而不是让它无限制地增长，这可以避免消耗设备上的大量空间，并避免ibdatal文件变得非常大的情况。在本书写作的时候，标准InnoDB还不能配置插入缓存的容量上限，但是在Percona XtraDB (Percona Sever和MariaDB都包含XtraDB)里可以。MySQL 5.6里也会增加一个类似的变量。
除了上述的配置建议，我们还提出或讨论了其他些闪存优化策略。然而，不是所有的策略都非常容易明白，所以我们只是提到了一部分，最好自己研究在具体情况下的好处。首先是InnoDB的页大小。我们发现了不同的结果，所以我们现在还没有一个明确的建议。好消息是，在Percona Server中不需要重编译也能配置页面大小，在MySQL 5.6中这个功能也可能实现。以前版本的MySQL需要重新编译服务器才能使用不同大小的页面，所以大部分情况都是运行在默认的16KB页面。当页面大小更容易让更多人进行实验时，我们期待更多非标准页面大小的测试，可能能从中得到很多重要的结论。
另一个提到的优化是InnoDB页面校验(Checksum)的替代算法。当存储系统响应很快时，校验值计算可能开始成为I/O相关操作中显著影响时间的因素，并且对某些人来说这个计算可能替代I/O成为新的瓶颈。我们的基准测试还没有得出可适用于普遍场景的结论，所以每个人的情况可能有所不同。Percona XtraDB允许修改校验算法，MySQL 5.6 也有了这个功能。
可能已经提醒过了，我们提到的很多功能和优化在标准版本的InnoDB中是无效的。我们希望并且相信我们引人Percona Server和XtraDB中的改进点，最终将会被广“大用户接受。与此同时，如果正使用Oracle官方MySQL分发版本，依然可以对服务器采取措施为闪存进行优化。建议使用innodb file per_ table, 并且把数据文件目录放到闪存设备。然后移动ibdatal和日志文件，以及其他所有日志文件(二进制日志、复制日志，等等)，到RAID卷，正如我们之前讨论的。这会把随机I/O集中到闪存设备上，然后把大部分顺序写人的压力尽可能转移出闪存，因而可以节省闪存空间并且减少磨损。
另外，所有版本的MySQL服务器，都应该确认超线程开启了。当使用闪存存储时，这有很大的帮助，因为磁盘通常不再是瓶颈，任务会更多地从I/O密集变为CPU密集。
