MySQL性能优化系列-原理与概念

MySQL概述

MySQL数据库目前已被Oracle收购，并发展处多个版本。目前使用最普遍且免费的MySQL版本是MySQL Community（社区版），另外还有三个付费的MySQL版本MySQL Standard（MySQL标准版）、MySQL Enterprise（MySQL企业版）、MySQL Cluster（MySQL集群版），这三个版本是按照CPU内核进行费用计算，而且价格由低到高。最后Oracle还提供了两个微型的MySQL版本：MySQL Classic（经典版），这个版本的MySQL只提供了MyISAM存储引擎可是安装快速，占用空间较少；MySQL Embedded（嵌入式版本），这个版本的竞争软件是SQLite。虽然社区版本是免费的而且这个版本提供的功能也没有企业级版本丰富，一样的硬件条件下单节点性能也没有企业基本版优秀。可是咱们能够借助社区版本自身提供的功能和一些第三方软件配合使用，搭建起相对廉价且性能不俗的MySQL数据库集群。

当今MySQL正在被普遍的使用，支撑着无数互联网应用的数据层，不少抱着拿来主义的人，每每用的不得要领，出现这样或那样的性能问题，这是由于忽视了MySQL在应用的过程当中须要的持续调优过程，包括MySQL参数调优、架构部署调优、硬件调优、SQL调优等等。

数据库引擎的选择

MySQL数据库中最重要的一个概念就是数据库引擎，不一样的数据库引擎的工做原理存在很大差别最终形成MySQL数据库服务的性能差别。例如若是数据库引擎须要支持事务，就必须知足事务的基本特性——AICD特性（AICD：原子性、隔离性、一致性和永久性），那么天然就须要必定处理机制来实现这些特性。这样作的现实效果就是致使写入一样数据量的状况下，支持事务的数据库引擎比不支持事务的数据库引擎耗费更多的时间。

这里列举MySQL数据库社区版中支持的一部分数据库引擎：

• MEMORY：MEMORY存储引擎将表的数据彻底存放在内存中。在MySQL数据库的历史版本中和该数据库引擎相似的其它引擎是HEAP，后者曾是MySQL数据库中访问速度最快的数据库引擎。但因为这两种数据库引擎彻底工做在内存中，因此若是MySQL或者服务器从新启动，数据库引擎中保存的数据将会丢失。

• BLACKHOLE：中文名“黑洞”，使用BLACKHOLE数据库引擎的数据表不存储任何数据，只根据数据库操做过程记录二进制日志。它的主要做用是做为MySQL主从复制的中继器，而且能够在其上面添加业务过滤机制。

• MyISAM：MyISAM数据库引擎是MySQL数据库默认的数据库引擎。MyISAM使用一种表格锁定的机制，来优化多个并发的读写操做（实际上就是使用的一种避免数据脏读的机制）。可是这种机制对存储空间的使用有必定的浪费。MyISAM还有一些有用的扩展，例如用来修复数据库文件的MYISAMCHK工具和用来恢复浪费空间的MYISAMPACK工具。

• InnoDB：InnoDB数据库引擎是在各类版本的MySQL数据库中使用最普遍的一种数据库引擎，本文后续的介绍中若是没有特别说明都默认是在说InnoDB数据库引擎。InnoDB数据库引擎使用日志机制提供事务的支持。

基本I/O性能

对于数据库的优化，须要从整个计算机体系的发展角度考虑。在今天CPU、GPU、内存频率、总线带宽都获得快速发展，使得计算能力获得质的提高，可是存储机制（除了机械硬盘、固态硬盘、磁盘阵列），没有更加革命性的变化。而传统的关系型数据库，在保证ACID的原则下，持久化是保证一致性的重要手段。所以，如何大幅度提高IO的性能，是数据库优化的重点之一。

要了解MySQL数据库中的性能问题，就首先要搞清楚在客户端向MySQL数据库提交一个事务操做时后者到底作了些什么事情，以及主要是怎么作的。本节所描述的工做过程主要围绕InnoDB数据库引擎进行：

上图中只画出了InnoDB数据库引擎在insert/update一个事务的过程当中所涉及的重要工做区域，InnoDB的实际工做细节要比上图所示的步骤复杂得多。

上文已经说到InnoDB数据库引擎是一个支持事务的数据库引擎，那么如何解决异常崩溃状况下的数据一致性问题就是它的设计中最重要的任务之一。InnoDB数据库引擎采用“日志机制提供事务的支持”来解决这个问题，请注意这里说的InnoDB数据库引擎日志，并非MySQL数据库全局的二进制日志。InnoDB数据库引擎日志还有另一个名字：重作日志（redo log），这是由于这部分日志主要的做用就是在数据库异常崩溃并重启后进行InnoDB引擎中数据的恢复。

为了提升MySQL数据库的性能，InnoDB数据库引擎的数据操做过程基本上都在内存中完成，而后经过必定的策略将InnoDB Log Buffer内存区域中的日志数据同步到磁盘上的InnoDB File Log Group区域。

InnoDB File Log Group区域主要用于存储InnoDB数据库引擎的日志文件，它由多个大小相同的日志文件构成而且这些文件都采用顺序读写。innodb_log_file_size参数将决定每一个文件的大小，而innodb_log_files_in_group参数将决定整个日志组中有多少个日志文件。当MySQL数据库完成初始化过程后这些日志文件将会按照参数的设置值，在磁盘上预占一个连续的磁盘空间。日志文件的总大小就已是 innodb_log_file_size * innodb_log_files_in_group所获得的数值了：

这样作的目的是保证了后续同步日志数据的操做都是顺序写，而不是随机写，以提升IO的效率。当日志数据写到最后一个文件的末尾时，下一条日志数据又会从新从第一个日志文件的开始位置进行写入。

MySQL I/O 性能问题的产生

InnoDB Log Buffer内存空间中的四个标识指针是InnoDB数据库引擎日志处理部分最重要元素，它们分别是：Log sequence、Log flushed、Pages flushed、Last checkpoint，这四个标识涉及到InnoDB在崩溃重启时不一样的数据恢复策略，以及I/O性能优化中的关键原理。

这四个标识，其实是四个数值。它们共享一个数值池（名叫LSN，log sequence number，日志序列号，其总长度是64位无符号整数），表明当前InnoDB对事务操做的“检查点或持久点”，而且它们之间的检查点数值关系特征以下：

Log sequence 大于等于 Log flushed 大于等于 Pages flushed 大于等于 Last checkpoint

1. 分配LSN。每当InnoDB接收到一个完整数据库insert/update请求事务后，就会建立一个新的LSN。新的LSN = 旧的LSN + 本次写入的日志大小。这条最新的日志将会使用Log sequence进行标记，而且若是出现接收到多个事务请求的状况下，InnoDB也会按照一个既定的顺序对这些日志进行排序，而后依次生成新的LSN。这一步骤是彻底在内存中进行的，因此不存在I/O性能问题。

2. 处理事务中的操做，写入InnoDB File Log Group日志文件。InnoDB数据库引擎专门有一个InnoDB Buffer Pool内存空间用来进行数据更改或数据新增。其大小由innodb_buffer_pool_size参数控制，其数据来源于innoDB data file而且以Page的形式存在于InnoDB Buffer Pool中。当日志中有insert操做时则生成新的Page；当日志中有update操做时，InnoDB会检查该数据是否已经存在于Page Cache中，若是存在（命中）就直接更新这个Page Cache中的内容，若是不存在（未命中）就会继续从InnoDB data file中读取（支持预读机制）原始数据到InnoDB Buffer Pool中而后再更新。

   当InnoDB完成InnoDB Buffer Pool中的数据操做后，更改后数据所涉及到的Page将和此时存储在磁盘上的数据不同，这样的Page称为脏页。
   
   如何控制脏页是保持数据一致性的关键。InnoDB数据库引擎的作法是：首先向InnoDB File Log Group日志文件中写入这个事务的日志信息（写入策略由innodb_flush_log_at_trx_commit参数决定）；而后InnoDB数据库引擎在这一步骤的最后一个动做是更改Log flushed标识指针值为当前最后完成刷新动做的事务日志LSN值。实际上执行完这个步骤，一个事务处理操做才算真正成功。

3. 将脏页写入磁盘。上面两个步骤，涉及数据变更的脏页尚未更新到磁盘上，为何事物的处理就能够算做成功了呢？这是由于即便这个时候数据库异常崩溃了，就凭存储在磁盘上的完整日志咱们也能够重作数据。可是最好仍是尽快同步脏页吧。在第三个步骤InnoDB数据库引擎将会把最近Log flush时所涉及到的脏页（最旧脏页）更新到磁盘上。当完成脏页向磁盘的同步操做后，InnoDB数据库引擎将会更新Pages flushed标识点的LSN值，表示这个LSN值所表明的事务（以及以前LSN的事务）都已经完成了内存和磁盘上的数据同步动做。
   
   当InnoDB数据库引擎进行脏页更新时，将会按照必定的周期策略批量提交脏页到Linux操做系统的cache memory区块中。不一样版本InnoDB数据库引擎支持的pages flush策略是不同的，但最基本的规则没有变化，就是周期性刷新。每一次批量提交的脏页数量由innodb_io_capacity_max参数决定。

   从Mysql version 5.6开始InnoDB数据库引擎向管理者提供了一个innodb_adaptive_flushing参数，InnoDB数据库引擎将检测脏页在InnoDB Buffer Pool中的比例，以及即时I/O状态等状况来决定pages flush的周期。若是脏页在InnoDB Buffer Pool中的比例达到了由innodb_max_dirty_pages_pct（默认为75）参数设置的百分比阀值，这时InnoDB数据库引擎将按照innodb_io_capacity_max（默认值2000）参数设置的数量将这写脏页一块儿同步到磁盘。

   当磁盘I/O性能不足，且innodb_io_capacity设置过大时，会致使产生较长的I/O队列形成I/O请求阻塞，一旦累积到innodb_max_dirty_pages_pct阀值，又会产生更长的I/O阻塞队列；反之则会形成物理服务器的I/O性能没有被去彻底使用。因此innodb_io_capacity的设置很是重要，特别是当读者在硬件层采用SSD固态硬盘和高速磁盘阵列时。

4. Checkpoint是InnoDB数据库引擎中最后一个标识点。这个标识点表明着当数据库异常崩溃重启后，小于或者等于这个标识点LSN值的全部日志信息、数据信息都无需进行重作检查。而LSN值大于Checkpoint的全部事务都须要重作，只是重作策略将视LSN值所在标识区域的不一样而不一样：

   • 当表明事务的LSN数值在Log sequence——Log flushed范围内时（不包括Log flushed），说明在数据库崩溃时内存中的事务并无处理完，这部分事务操做将在恢复时被丢弃。

   • 当表明事务的LSN数值在Log flushed——Pages flushed范围内时（不包括Pages flushed），说明数据库崩溃时磁盘上已经拥有这些事务完整的日志记录。InnoDB数据库引擎将读取这些日志数据，并继续执行下去，直到表明这些事务的LSN值被标记为Checkpoint（或者小于Checkpoint标识的LSN值）。这里要注意，在数据库崩溃时处于这个范围内的某些事务可能已经完成了一部分的数据同步动做，可是确定是不完整的。因此即便是这样的事务也要从新进行磁盘同步，才能保证数据的一致性。

   • 实际上在MySQL version 5.5的早期版本，InnoDB数据库引擎中只有三个标识：Log sequence、Log flushed和Checkpoint。也就是说当脏页成功同步到磁盘后，就会直接更新Checkpoint标识的LSN值。后续版本的MySQL数据库增长了Pages flushed标识点，这样作的目的是保证Checkpoint和Pages flush的更新能够拥有独立的周期，从而下降其带来的性能消耗。

Log flush和Pages flush

咱们大体知道了在InnoDB数据库引擎中一个事务的处理过程当中有两个步骤存在I/O操做：Log flush和Pages flush。

Log flush的过程是将完成的事务日志写入到日志文件中，因为InnoDB数据库引擎中日志文件的组织方式（创建在块存储方案上，对于大部分关系型数据库都适用。而不是创建在文件存储方案或者对象存储方案上），Log flush中对磁盘的操做是顺序写。而且技术团队还能够经过innodb_flush_log_at_trx_commit参数来调整InnoDB Log Buffer到InnoDB File Log Group的写入策略，这有助于进一步提升Log flush性能。

Pages flush的过程就没有那么幸运了，InnoDB数据库引擎不可能事先知道数据库会存放哪些数据，也不可能知道下次的update操做和select操做的目标数据存放在哪一个区域。因此InnoDB数据库引擎针对Page的读取和更新都只能基于随机读写。那么Pages flush过程就须要在如何保持I/O性能这问题上想更多的解决办法。

• 预读预写机制。例如在读取Page时，采用“预读”思路将目标Page所临近的Page一块儿读取出来；在写入Page时将目标Page所临近的Page一块儿写入（“临近写”）。“预读”策略能够经过innodb_read_ahead_threshold参数进行设置，并经过read thread完成，另外 innodb_flush_neighors参数能够控制是否开启“临近写”策略。总的来讲“预读”/“临近写”在默认状况下都是开启的，但“预读”/“临近写”思路自己就须要必定的准确性，低命中率的“预读”反而会下降InnoDB的I/O性能。还有一种“随机预读”，它在MySQL version 5.6版本中默认就是关闭的，而且在随后的版本中将会慢慢废除，所以这里就再也不介绍了。

• 批量执行机制。例如将向磁盘提交Page的动做设计为周期性且批量进行，而且始终保持InnoDB Buffer Pool内存区域的脏页（Dirty Page）在必定的比例，这些策略主要由innodb_io_capacity、innodb_max_dirty_pages_pct、innodb_io_capacity_max等参数控制。

• 提升内存命中率和利用率。例如经过调整Innodb_Buffer_Pool_size参数得到更大的InnoDB Buffer Pool内存区域，存储更多的Page。实际上Innodb Buffer Pool区域不只包括咱们已经介绍的Page Cache数据部分，还包括其它的数据区块。例如为了快速定位B+树索引的Hash Index结构。调整Innodb_Buffer_Pool_size参数将会使这些数据区域都享受到内存容量带来的优点——至少不会频繁地发生内容空间的强制清理。