mysql调优笔记怎么调 mysql怎么优化( 五 )


基本上 , innodb_buffer_pool_size指定了MySQL应该分配给InnoDB缓冲池多少内存,InnoDB缓冲池用来存储缓存的数据 , 二级索引,脏数据(已经被更改但没有刷新到硬盘的数据)以及各种内部结构如自适应哈希索引 。
根据经验 , 在一个独立的MySQL服务器应该分配给MySQL整个机器总内存的80% 。如果你的MySQL运行在一个共享服务器,或者你想知道InnoDB缓冲池大小是否正确设置,详细请看这里 。
3.INNODB_LOG_FILE_SIZE
InnoDB重做日志文件的设置在MySQL社区也叫做事务日志 。直到MySQL 5.6.8事务日志默认值innodb_log_file_size=5M是唯一最大的InnoDB性能杀手 。从MySQL 5.6.8开始,默认值提升到48M,但对于许多稍繁忙的系统 , 还远远要低 。
根据经验,你应该设置的日志大小能在你服务器繁忙时能存储1-2小时的写入量 。如果不想这么麻烦,那么设置1-2G的大小会让你的性能有一个不错的表现 。这个变量也相当重要,更详细的介绍请看这里 。
当然,如果你有大量的大事务更改,那么,更改比默认innodb日志缓冲大小更大的值会对你的性能有一定的提高,但是你使用的是autocommit,或者你的事务更改小于几k,那还是保持默认的值吧 。
4.INNODB_FLUSH_LOG_AT_TRX_COMMIT
默认下,innodb_flush_log_at_trx_commit设置为1表示InnoDB在每次事务提交后立即刷新同步数据到硬盘 。如果你使用autocommit,那么你的每一个INSERT, UPDATE或DELETE语句都是一个事务提交 。
同步是一个昂贵的操作(特别是当你没有写回缓存时),因为它涉及对硬盘的实际同步物理写入 。所以如果可能,并不建议使用默认值 。
两个可选的值是0和2:
* 0表示刷新到硬盘,但不同步(提交事务时没有实际的IO操作)
* 2表示不刷新和不同步(也没有实际的IO操作)
所以你如果设置它为0或2,则同步操作每秒执行一次 。所以明显的缺点是你可能会丢失上一秒的提交数据 。具体来说,你的事务已经提交了 , 但服务器马上断电了,那么你的提交相当于没有发生过 。
显示的,对于金融机构,如银行,这是无法忍受的 。不过对于大多数网站,可以设置为innodb_flush_log_at_trx_commit=0|2,即使服务器最终崩溃也没有什么大问题 。毕竟,仅仅在几年前有许多网站还是用MyISAM,当崩溃时会丢失30s的数据(更不要提那令人抓狂的慢修复进程) 。
那么 , 0和2之间的实际区别是什么?性能明显的差异是可以忽略不计,因为刷新到操作系统缓存的操作是非常快的 。所以很明显应该设置为0 , 万一MySQL崩溃(不是整个机器),你不会丢失任何数据,因为数据已经在OS缓存,最终还是会同步到硬盘的 。
5.SYNC_BINLOG
已经有大量的文档写到sync_binlog,以及它和innodb_flush_log_at_trx_commit的关系,下面我们来简单的介绍下:
a) 如果你的服务器没有设置从服务器,而且你不做备份,那么设置sync_binlog=0将对性能有好处 。
b) 如果你有从服务器并且做备份,但你不介意当主服务器崩溃时在二进制日志丢失一些事件 , 那么为了更好的性能还是设置为sync_binlog=0.
c) 如果你有从服务器并且备份,你非常在意从服务器的一致性,以及能及时恢复到一个时间点(通过使用最新的一致性备份和二进制日志将数据库恢复到特定时间点的能力) , 那么你应该设置innodb_flush_log_at_trx_commit=1,并且需要认真考虑使用sync_binlog=1 。
问题是sync_binlog=1代价比较高 – 现在每个事务也要同步一次到硬盘 。你可能会想为什么不把两次同步合并成一次,想法正确 – 新版本的MySQL(5.6和5.7,MariaDB和Percona Server)已经能合并提交,那么在这种情况下sync_binlog=1的操作也不是这么昂贵了,但在旧的mysql版本中仍然会对性能有很大影响 。

推荐阅读