MySQL5.6基本优化配置

随着 大量默认选项的改进, MySQL 5.6比之前版本须要调优的选项大为减小. 在本文中我将讲述须要优化的配置项.

InnoDB设置

1.innodb_buffer_pool_size  —— 默认值为 128M. 这是最主要的优化选项,由于它指定 InnoDB 使用多少内存来加载数据和索引(data+indexes). 针对专用MySQL服务器,建议指定为物理内存的 50-80%这个范围. 例如,拥有64GB物理内存的机器,缓存池应该设置为50GB左右. 
若是将该值设置得更大可能会存在风险,好比没有足够的空闲内存留给操做系统和依赖文件系统缓存的某些MySQL子系统(subsystem),包括二进制日志(binary logs),InnoDB事务日志(transaction logs)等.

2.innodb_log_file_size —— 默认值为 48M. 有很高写入吞吐量的系统须要增长该值以容许后台检查点活动在更长的时间周期内平滑写入,得以改进性能. 将此值设置为4G如下是很安全的. 过去的实践代表,日志文件太大的缺点是增长了崩溃时所需的修复时间,但这在5.5和5.6中已获得重大改进.

3.innodb_flush_method  —— 默认值为 fdatasync. 若是使用 硬件RAID磁盘控制器, 可能须要设置为 O_DIRECT. 这在读取InnoDB缓冲池时可防止“双缓冲(double buffering)”效应,不然会在文件系统缓存与InnoDB缓存间造成2个副本(copy). 
若是不使用硬件RAID控制器,或者使用SAN存储时, O_DIRECT 可能会致使性能降低.MySQL用户手册 和 Bug #54306  详细地说明了这一点.

4.innodb_flush_neighbors —— 默认值为 1. 在SSD存储上应设置为0(禁用) ,由于使用顺序IO没有任何性能收益. 在使用RAID的某些硬件上也应该禁用此设置,由于逻辑上连续的块在物理磁盘上并不能保证也是连续的.

5.innodb_io_capacity and innodb_io_capacity_max —— 这些设置会影响InnoDB每秒在后台执行多少操做. 若是你深度了解硬件性能(如每秒能够执行多少次IO操做),则使用这些功能是很可取的,而不是让它闲着.

有一个很好的类比示例:  假如某次航班一张票也没有卖出去 —— 那么让稍后航班的一些人乘坐该次航班,有多是很好的策略,以防后面遇到恶劣的天气. 即有机会就将后台操做顺便处理了,以减小同稍后可能的实时操做产生竞争.

 有一个很简单的计算:  若是每一个磁盘每秒读写(IOPS)能够达到 200次, 则拥有10个磁盘的 RAID10 磁盘阵列IOPS理论上 =(10/2)* 200 = 1000. 我说它“很简单”,是由于RAID控制器一般可以提供额外的合并,并有效提升IOPS能力. 对于SSD磁盘,IOPS能够轻松达到好几千.

 将这两个值设置得太大可能会存在某些风险,你确定不但愿后台操做妨碍了前台任务IO操做的性能. 过去的经验代表,将这两个值设置的过高,InnoDB持有的内部锁会致使性能下降(按我了解到的信息,在MySQL5.6中这获得了很大的改进).

innodb_lru_scan_depth - 默认值为 1024. 这是mysql 5.6中引入的一个新选项. Mark Callaghan  提供了 一些配置建议. 简单来讲,若是增大了 innodb_io_capacity 值, 应该同时增长 innodb_lru_scan_depth.

复制(Replication)

假如服务器要支持主从复制,或按时间点恢复,在这种状况下,咱们须要:

1.log-bin —— 启用二进制日志. 默认状况下二进制日志不是事故安全的(not crash safe),但如同我 之前的文章所说, 我建议大多数用户应该以稳定性为目标. 在这种状况下,你还须要启用: sync_binlog=1, sync_relay_log=1, relay-log-info-repository=TABLE and master-info-repository=TABLE.

2.expire-logs-days —— 默认旧日志会一直保留. 我推荐设置为 1-10 天. 保存更长的时间并无太多用处,由于从备份中恢复会快得多.

3.server-id —— 在一个主从复制体系(replication topology )中的全部服务器都必须设置惟一的 server-id.

4.binlog_format=ROW  —— 修改成基于行的复制. 我最近写的另外一篇 基于行的复制 ,里面叙述了我真的很喜欢它的缘由,由于它能够经过减小资源锁定提升性能. 此外还须要启用两个附加设置:  transaction-isolation=READ-COMMITTED and  innodb_autoinc_lock_mode = 2.

其余配置(Misc)

1.timezone=GMT  将时区设置为格林尼治时间. 愈来愈多的系统管理员建议将全部服务器都设置为 格林尼治时间(GMT). 我我的很是喜欢这点,由于如今几乎全部的业务都是全球化的. 设置为你本地的时区彷佛是有点武断的.

2.character-set-server=utf8mb4 and collation-server=utf8mb4_general_ci  如以前的 文章所讲述的 ,utf8 编码对新应用来讲是更好的默认选项. 您还能够设置 skip-character-set-client-handshake 以忽略应用程序想要设置的其余字符集(character-set).

3.max_connect_errors —— Todd Farmer 写道 :“[这个功能]提供了没有实际意义的暴力访问攻击保护”. 事实上当设置skip-name-resolve 时, max_connect_errors 甚至不起做用(见上一段所述).

 防火墙是更合适的解决方案,一般我将3306端口屏蔽,不论是公网的仍是内网的端口,只有特定的应用程序能够访问和链接到MySQL. 
 我一般会设置 max_connect_errors=100000, 这样我能够避免任何“双重配置”,保证它不会碍事.

4.max-connections ——默认值是151. 我看到不少用户将他设置得比较大,大多在 300 ~ 1000之间.
 一般不可避免地这个值会被设置得更大,但让我有点紧张的是, 16核的机器在IO阻塞的状况下也只有大约 2x~10x 的链接执行能力. 
 你可能但愿,许多打开的链接都是空闲并休眠的. 但若是他们都处于活跃状态的话,可能会建立大量新的线程(thread-thrash).
 若是条件容许,能够为应用程序配置优化数据库链接池(connection-pools)来解决这个问题,而不是打开并保持大量链接; 
 固然那些不使用链接池(non-pooled ), 迅速打开,执行任务后又尽量快地关闭链接的应用也是可行的. 
 从5.5开始的另外一种解决方案(在MySQL社区版和企业版之间有一些差别) 是使用 线程池插件.

总结(Conclusion)

假设MySQL服务器的配置为:
1.64GB物理内存
2.硬件RAID控制器(假设每秒IO可达 2000 IOPS)
3.须要主从复制(Replication)
4.新的应用(eg. 非遗留系统)
5.有防火墙保护
6.不须要基于域名(hostnames,主机名)的受权
7.全球化应用,并不想固定在某一时区.
8.想要程序可靠稳定(durable).

则配置可能以下所示:

复制代码代码以下:

# InnoDB settings
innodb_buffer_pool_size=50G
innodb_log_file_size=2G
innodb_flush_method=O_DIRECT
innodb_io_capacity=2000
innodb_io_capacity_max=6000
innodb_lru_scan_depth=2000

# Binary log/replication
log-bin
sync_binlog=1
sync_relay_log=1
relay-log-info-repository=TABLE
master-info-repository=TABLE
expire_logs_days=10
binlog_format=ROW
transaction-isolation=READ-COMMITTED
innodb_autoinc_lock_mode = 2

# Other
timezone=GMT
character-set-server=utf8
collation-server=utf8_general_ci
max-connect-errors=100000
max-connections=500

# Unique to this machineserver-id=123