[MySQL] Innodb參数优化

innodb_buffer_pool_size

innodb_buffer_pool_size 參数用来设置Innodb 最基本的Buffer(Innodb_Buffer_Pool)的大小，也就是缓存用户表及索引数据的最主要缓存空间，对Innodb 总体性能影响也最大。

对于一台单独给MySQL 使用的主机，并如果仅仅使用innodb引擎。一般建议该參数为物理内存的75%左右。

当系统上线之后，我们能够通过Innodb 存储引擎提供给我们的关于Buffer Pool 的实时状态信息作出进一步分析。来确定系统中Innodb 的Buffer Pool 使用情况是否正常高效：

mysql> show status like 'Innodb_buffer_pool_%';
+-----------------------------------------+---------------+
| Variable_name                           | Value         |
+-----------------------------------------+---------------+
| Innodb_buffer_pool_pages_data           | 999020        | 
| Innodb_buffer_pool_pages_dirty          | 47643         | 
| Innodb_buffer_pool_pages_flushed        | 474668167     | 
| Innodb_buffer_pool_pages_LRU_flushed    | 365125        | 
| Innodb_buffer_pool_pages_free           | 0             | 
| Innodb_buffer_pool_pages_made_not_young | 0             | 
| Innodb_buffer_pool_pages_made_young     | 203410903     | 
| Innodb_buffer_pool_pages_misc           | 49552         | 
| Innodb_buffer_pool_pages_old            | 368697        | 
| Innodb_buffer_pool_pages_total          | 1048572       | 
| Innodb_buffer_pool_read_ahead_rnd       | 0             | 
| Innodb_buffer_pool_read_ahead           | 66348855      | 
| Innodb_buffer_pool_read_ahead_evicted   | 3716819       | 
| Innodb_buffer_pool_read_requests        | 3215992991498 | 
| Innodb_buffer_pool_reads                | 65634998      | 
| Innodb_buffer_pool_wait_free            | 651           | 
| Innodb_buffer_pool_write_requests       | 21900970785   | 
+-----------------------------------------+---------------+

从上面的值我们能够看出总共1048572个 pages，当中放数据的有999020个 pages，且已没有free状态的page。

read 请求3215992991498次，当中有65634998次所请求的数据在buffer pool 中没有。也就是说有65634998 次是通过读取物理磁盘来读取数据的，所以非常easy也就得出了Innodb Buffer Pool 的Read 命中率大概在为：(3215992991498- 65634998)/ 3215992991498* 100% = 99.998%。

innodb_buffer_pool_instances

该參数将innodb_buffer_pool划分为不同的instance，每一个instance独立的LRU、FLUSH、FREE、独立的mutex控制。

对于比較大的innodb_buffer_pool_size，建议设置多个instances。避免内存锁的争用。

innodb_log_file_size

设置innodb redo log file的大小，从性能角度来看。日志文件越大越好，能够降低buffer pool checkpoint的频率。可是在MySQL的官方版本号中。iinnodb_log_file_size*innodb_log_files_in_group不能超过4G。

日志文件越大。也意味着MySQL实例crash之后恢复的时间越长，只是一般生成系统都会配置主从库，因此这个因素能够忽略不考虑。

一般来说，在我个人维护的环境中，比較偏向于将事务日志设置为3 组，每一个日志设置为256MB 大小，总体效果还算不错。

innodb_log_buffer_size

顾名思义。这个參数就是用来设置Innodb 的Log Buffer 大小的，系统默认值为1MB。Log Buffer的主要作用就是缓冲Log 数据，提高写Log 的IO 性能。

一般来说，假设你的系统不是“写负载很高且以大事务居多”的话，8MB 以内的大小就全然足够了。

我们也能够通过系统状态參数提供的性能统计数据来分析Log 的使用情况：

mysql> show status like 'innodb_log%';
+---------------------------+------------+
| Variable_name             | Value      |
+---------------------------+------------+
| Innodb_log_waits          | 0          | 
| Innodb_log_write_requests | 3486920147 | 
| Innodb_log_writes         | 352577360  | 
+---------------------------+------------+

假设Innodb_log_waits不等于0的话。表示出现过Log Buffer的写等待。表示innodb_log_buffer_size有可能过小。

innodb_thread_concurrency

该參数表示innodb最大线程并发量，官方推荐设为0，表示由innodb自己控制，但实践证明，当并发过大时，innodb自己会控制不当。可能导致MySQL hang死，所以一般建议为CPU核心数（不含超线程）

innodb_io_capacity

表示每秒钟IO设备处理数据页的上限，假设硬盘性能比較好，能够设大一些（如1000）。

innodb_max_dirty_pages_pct

表示innodb从buffer中刷新脏页的比例不超过这个值，每次checkpoint的脏页刷新为：innodb_max_dirty_pages_pct*innodb_io_capacity

Innodb_flush_method

用来设置Innodb 打开和同步数据文件以及日志文件的方式，只是仅仅有在Linux & Unix 系统上面有效。

当我们设置为O_DSYNC，则系统以O_SYNC 方式打开和刷新日志文件。 通过fsync() 来打开和刷新数据文件。

而设置为O_DIRECT 的时候。 则通过O_DIRECT（Solaris 上为directio()）打开数据文件，同一时候以fsync()来刷新数据和日志文件。
总的来说。innodb_flush_method 的不同设置主要影响的是Innodb 在不同执行平台下进行IO 操作的时候所调用的操作系统IO 借口的差别。而不同的IO 操作接口对数据的处理方式会有一定的差别，所以处理性能也会有一定的差异。一般来说。假设我们的磁盘是通过RAID 卡做了硬件级别的RAID，建议能够使用O_DIRECT，能够一定程度上提高IO 性能。但假设RAID Cache 不够的话。还是须要慎重对待。

innodb_file_per_table

一般建议开启。由于不同的表空间能够灵活设置数据文件夹的地址，避免共享表空间产生的IO竞争。

innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit = 0，Innodb 中的Log Thread 每隔1 秒钟会将log buffer中的数据写入到文件。同一时候还会通知文件系统进行文件同步的flush 操作，保证数据确实已经写入到磁盘上面的物理文件。可是。每次事务的结束（commit 或者是rollback）并不会触发Log Thread 将log buffer 中的数据写入文件。

所以。当设置为0 的时候，当MySQL Crash 和OS Crash 或者主机断电之后，最极端的情况是丢失1 秒时间的数据变更。

innodb_flush_log_at_trx_commit = 1。这也是Innodb 的默认设置。我们每次事务的结束都会触发Log Thread 将log buffer 中的数据写入文件并通知文件系统同步文件。

这个设置是最安全的设置，可以保证不论是MySQL Crash 还是OS Crash 或者是主机断电都不会丢失不论什么已经提交的数据。

innodb_flush_log_at_trx_commit = 2，当我们设置为2 的时候。Log Thread 会在我们每次事务结束的时候将数据写入事务日志。可是这里的写入不过调用了文件系统的文件写入操作。而我们的文件系统都是有缓存机制的。所以Log Thread 的这个写入并不能保证内容真的已经写入到物理磁盘上面完毕持久化的动作。文件系统什么时候会将缓存中的这个数据同步到物理磁盘文件Log Thread 就全然不知道了。所以，当设置为2 的时候。MySQL Crash 并不会造成数据的丢失，可是OS Crash 或者是主机断电后可能丢失的数据量就全然控制在文件系统上了。

从上面的分析我们能够看出。当innodb_flush_log_at_trx_commit 设置为1 的时候是最安全的。可是因为所做的IO 同步操作也最多，所以性能也是三种设置中最差的一种。假设设置为0。则每秒有一次同步，性能相对高一些。假设设置为2，可能性能是三这样的最好的。可是也可能是出现Crash后丢失数据最多的。

究竟该怎样设置设置，就要依据详细的场景来分析了。一般来说，假设全然不能接受数据的丢失，那么我们肯定会通过牺牲一定的性能来换取数据的安全性。选择设置为1。

而假设我们能够丢失非常少量的数据(比方说1 秒之内)。那么我们能够设置为0。当然。假设大家认为我们的OS 足够稳定。主机硬件设备，并且主机的供电系统也足够安全，我们也能够将innodb_flush_log_at_trx_commit 设置为2 让系统的总体性能尽可能的高。

transaction-isolation

对于高并发应用来说。为了尽可能保证数据的一致性，避免并发可能带来的数据不一致问题。自然是事务隔离级别越高越好。可是。对于Innodb 来说。所使用的事务隔离级别越高，实现复杂度自然就会更高，所须要做的事情也会很多其它。总体性能也就会更差。

所以。我们须要分析自己应用系统的逻辑，选择能够接受的最低事务隔离级别。以在保证数据安全一致性的同一时候达到最高的性能。
尽管Innodb 存储引擎默认的事务隔离级别是REPEATABLE READ。但实际上在我们大部分的应用场景下，都仅仅须要READ COMMITED 的事务隔离级别就能够满足需求了。

sync_binlog

表示每次刷新binlog到磁盘的数目。

对于核心系统，我们须要採用双1模式，即：innodb_flush_log_at_trx_commit=1, sync_binlog=1，这样能够保证主备库数据一致，不会有数据丢失。