优化服务器设置

配置MySQL的IO行为

有一些配置影响着MySQL怎样同步数据到磁盘以及如何做恢复操作。这些操作对性能的影响非常大，因为都涉及到昂贵的IO操作。它们也表现了性能和数据安全之间的权衡。通常，保证数据立刻并且一致地写到磁盘是很昂贵的。如果能够冒一点磁盘写可能没有真正持久化到磁盘的风险，就可以增加并发性和减少IO等待，但是必须决定可以容忍多大的风险

InnoDB的IO配置

InnoDB不仅允许控制怎么恢复，还允许控制怎么打开和刷新数据(文件)，这会对恢复和整体性能产生巨大的影响。尽管7可以影响它的行为，InnoDB的恢复流程实际上是自动的，并且经常在InnoDB启动时运行。撇开恢复并假设InnoDB没有崩溃或者出错，InnoDB依然有很多需要配置的地方。它有一系列复杂的缓存和文件涉及可以提升性能，以及保证ACID特性，并且每一部分都是可配置的，
如图所示。对于常见的应用，最重要的一小部分内容是InnoDB日志文件大小、InnoDB怎样刷新它的日志缓冲，以及InnoDB怎样执行IO.

InnoDB事务日志(包含:Redo log 重做日志和Undo log回滚日志)

InnoDB使用日志来减少提交事务时的开销，因为日志中已经记录了事务，就无须在每个事务提交时把缓冲池的脏块刷新(flush)到磁盘中。事务修改的数据和索引通常会映射到表空间的随机位置，所以刷新这些变更到磁盘需要很多随机IO.InnoDB假设使用的时常规磁盘(机械磁盘)，随机IO比顺序IO要昂贵很多，因为一个IO请求需要时间把磁头移到正确的位置，然后等待磁盘上读出需要的部分，再转到开始位置。InnoDB用日志把随机IO变成顺序IO.一旦日志安全写到磁盘，事务就持久化了，即使变更还没写到数据文件，如果一些糟糕的事情发生了(例如断电了)，InnoDB可以重放日志并且恢复已经提交的事务。当然，InnoDB最后还是必须把变更写到数据文件，因为日志有固定的大小。InnoDB的日志是环形方式写的:当写到日志的尾部，会重新跳转到开头继续写，但不胡覆盖还没应用到数据文件的日志记录，因为这样做会清掉已提交事务的唯一持久化记录。
InnoDB使用一个后台线程智能地刷新这些变更到数据文件。这个线程可以批量组合写入，使得数据写入更顺序，以提高效率。实际上，事务日志把数据文件的随机IO转换为几乎顺序的日志文件和数据文件IO.把刷新操作转移到后台使查询可以更快完成，并且缓和查询高峰时IO系统的压力。
整体的日志文件受控于innodb_log_file_size和innodb_log_files_in_group两个参数，这对写性能非常重要。日志文件的总大小是每个文件的大小之和。默认情况下，只有两个5MB的文件，总共10MB。对高性能工作来说这太小了。至少需要几百MB，或者甚至上GB的日志文件。
InnoDB使用多个文件作为一组循环日志，通常不需要修改默认的日志数量，只修改每个日志文件的大小即可。要修改日志文件大小，需要完全关闭MySQL，将旧的日志文件移到其他地方保存，重新配置参数，然后重启。一定要确保MySQL干净地关闭了，或者还有日志文件可以保证需要应用到数据文件的事务记录，否则数据库就无法恢复了。当重启服务器的时候，查看MySQL的错误日志。在重启成功之后，才可以删除旧的日志文件。
日志文件大小和日志缓存。要确定理想的日志文件大小，必须权衡正常数据变更的开销和崩溃恢复需要鞥多时间。如果日志太小，InnoDB将必须做更多的检查点，导致更多的日志写。在极个别情况下，写语句可能被拖累，在日志没有空间继续写入前，必须等待变更被应用到数据文件。另一方面，如果日志太大了，在崩溃恢复时InnoDB可能不得不做大量的工作。这可能极大地增加恢复时间，尽管这个处理在新的MySQL版本中已经改善很多。
数据大小和访问模式也将影响恢复时间。假设有一个1TB的数据和16GB的缓冲池，并且全部日志大小是128MB。如果缓冲池里面有很多脏页(例如，页被修改了还没被刷写回数据文件)，并且它们均匀地分布在1TB数据中，崩溃后恢复将需要相当长一段时间。InnoDB必须从头到尾扫描日志，仔细检查数据文件，如果需要还要应用变更到数据文件。这是很庞大的读写操作！另一方面，如果变更是局部性的——就是说，如果只有几百MB数据被频繁地变更——恢复可能就很快，即使数据和日志文件很大。恢复时间也依赖普通修改操作的大小，这跟数据行地平均长度有关系。较短的行使得更多的修改而已放在同样的日志中，所以InnoDB可能必须在恢复时重放更多修改操作。
当InnoDB变更任何数据时，会写一条变更记录到内存日志缓冲区。在缓冲区满的时候、事务提交的时候，或者每一秒钟，InnoDB都会刷写缓冲区的内容打磁盘日志文件——无论上述三个条件哪个先达到。如果有大事务，增加日志缓冲区(默认1MB)大小可以帮助减少IO.变量innodb_log_buffer_size可以控制日志缓冲区的大小。
通常不需要把日志缓冲区设置得非常大。推荐的范围是1MB~8MB,一般来说足够了，除非要写很多相当大的BLOB记录。相对于InnoDB的普通数据，日志条目是非常紧凑的，它们不是基于页的，所以不会浪费空间来一次存储整个页。InnoDB也使得日志条目尽可能地端。有时甚至会保存为函数号和C函数的参数。
较大的日志缓冲区在某些情况下也是有好处的:可以减少缓冲区中空间分配的争用。当配置一台有打内存的服务器时，有时简单地分配32MB~128MB的日志缓冲，因为花费这么点相对(整机)而言比较小的内存并没有什么不好，还可以帮助避免压力瓶颈。如果有问题，瓶颈一般会表现为日志缓冲Mutex的竞争。
可以通过检查SHOW INNODB STATUS的输出中LOG部分来监控InnoDB的日志和日志缓冲区的IO性能，通过观察Innodb_os_log_written状态变量来查看InnoDB对日志文件写出了多少数据。一个好用的经验法则是，查看10~100秒间隔的数字，然后记录分支。可以用这个来判断日志缓冲是否设置得正好。例如，若看到峰值是每秒写100KB数据到日志，那么1MB的日志缓冲可能足够了，也可以使用这个衡量标准来决定日志文件设置多大会比较号。如果峰值是100KB/s,那么256MB的日志我呢见足够存储至少2560秒的日志记录。这看起来足够了。作为一个经验法则，日志文件的全部大小，应该足够容纳服务器一个小时的活动内容。

InnoDB怎样刷新日志缓冲。当InnoDB把日志缓冲刷新到磁盘文件时，先回使用一个Mutex锁住缓冲区，刷新到所需要的位置，然后移动剩下的条目到缓冲区的前面。当Mutex释放时，可能有超过一个事务已经准备好刷新其日志记录。InnoDB有一个Group Commit功能，可以在一个IO操作内提交多个事务，但是MySQL5.0中打开二进制日志时这个功能就不能用了。
日志缓冲必须被刷新到持久化存储，以确保提交的事务完全被持久化了。如果和持久化相比更在乎性能，可以修改innodb_flush_log_at_trx_commit变量来控制日志缓冲区刷新的频繁程度。

• 0
  把日志缓冲写到日志文件中，并且每秒钟刷新一次，但是事务提交时不做任何事
• 1
  将日志缓冲写到日志文件，并且每次事务提交都刷新到持久化存储。这是默认的(并且是最安全的)
  设置，该设置能保证不会丢失任何已经提交的事务，除非磁盘或者操作系统是"伪"刷新。
• 2
  每次提交时把日志缓冲写到日志文件，但是并不刷新。InnoDB每秒钟做一次刷新。0与2最重要的
  不同是(也是为什么2是更合适的设置)，如果MySQL进程"挂了"，2不会丢失任何事务。如果整个服务器
  "挂了"或者断电了，则还是i可能会丢失一些事务