mysql5.5怎么样 mysql5560( 二 )


5.SYNC_BINLOG
已经有大量的文档写到sync_binlog,以及它和innodb_flush_log_at_trx_commit的关系,下面我们来简单的介绍下:
【mysql5.5怎么样 mysql5560】 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版本中仍然会对性能有很大影响 。
6.INNODB_FLUSH_METHOD
将innodb_flush_method设置为O_DIRECT以避免双重缓冲.唯一一种情况你不应该使用O_DIRECT是当你操作系统不支持时 。但如果你运行的是Linux,使用O_DIRECT来激活直接IO 。
不用直接IO,双重缓冲将会发生,因为所有的数据库更改首先会写入到OS缓存然后才同步到硬盘 – 所以InnoDB缓冲池和OS缓存会同时持有一份相同的数据 。特别是如果你的缓冲池限制为总内存的50%,那意味着在写密集的环境中你可能会浪费高达50%的内存 。如果没有限制为50%,服务器可能由于OS缓存的高压力会使用到swap 。
简单地说,设置为innodb_flush_method=O_DIRECT 。
7.INNODB_BUFFER_POOL_INSTANCES
MySQL 5.5引入了缓冲实例作为减小内部锁争用来提高MySQL吞吐量的手段 。
在5.5版本这个对提升吞吐量帮助很小,然后在MySQL 5.6版本这个提升就非常大了,所以在MySQL5.5中你可能会保守地设置innodb_buffer_pool_instances=4,在MySQL 5.6和5.7中你可以设置为8-16个缓冲池实例 。
你设置后观察会觉得性能提高不大,但在大多数高负载情况下,它应该会有不错的表现 。
对了,不要指望这个设置能减少你单个查询的响应时间 。这个是在高并发负载的服务器上才看得出区别 。比如多个线程同时做许多事情 。
8.INNODB_THREAD_CONCURRENCY
InnoDB有一种方法来控制并行执行的线程数 – 我们称为并发控制机制 。大部分是由innodb_thread_concurrency值来控制的 。如果设置为0,并发控制就关闭了,因此InnoDB会立即处理所有进来的请求(尽可能多的) 。
在你有32CPU核心且只有4个请求时会没什么问题 。不过想像下你只有4CPU核心和32个请求时 – 如果你让32个请求同时处理,你这个自找麻烦 。因为这些32个请求只有4 CPU核心,显然地会比平常慢至少8倍(实际上是大于8倍),而然这些请求每个都有自己的外部和内部锁,这有很大可能堆积请求 。
下面介绍如何更改这个变量,在mysql命令行提示符执行:
对于大多数工作负载和服务器,设置为8是一个好开端,然后你可以根据服务器达到了这个限制而资源使用率利用不足时逐渐增加 。可以通过show engine innodb status\G来查看目前查询处理情况,查找类似如下行:
9.SKIP_NAME_RESOLVE
这一项不得不提及,因为仍然有很多人没有添加这一项 。你应该添加skip_name_resolve来避免连接时DNS解析 。
大多数情况下你更改这个会没有什么感觉,因为大多数情况下DNS服务器解析会非常快 。不过当DNS服务器失败时,它会出现在你服务器上出现“unauthenticated connections” ,而就是为什么所有的请求都突然开始慢下来了 。

推荐阅读