​


随着 ​​​​, MySQL 5.6比曾经版本号须要调优的选项大为降低. 在本文中我将讲述须要优化的配置项.


InnoDB设置

  • —— 默认值为 128M. 这是最基本的优化选项,由于它指定 InnoDB 使用多少内存来载入数据和索引(data+indexes). 针对专用MySQL服务器,建议指定为物理内存的 50-80%这个范围. 比如,拥有64GB物理内存的机器,缓存池应该设置为50GB左右. 
  • 假设将该值设置得更大可能会存在风险,比方没有足够的空暇内存留给操作系统和依赖文件系统缓存的某些MySQL子系统(subsystem),包含二进制日志(binary logs),InnoDB事务日志(transaction logs)等.
  • —— 默认值为 48M. 有非常高写入吞吐量的系统须要添加该值以同意后台检查点活动在更长的时间周期内平滑写入,得以改进性能. 将此值设置为4G下面是非常安全的. 过去的实践表明,日志文件太大的缺点是添加了崩溃时所需的修复时间,但这在5.5和5.6中已得到重大改进.
  • ​  —— 默认值为 fdatasync. 假设使用 硬件RAID磁盘控制器, 可能须要设置为 O_DIRECT. 这在读取InnoDB缓冲池时可防止“双缓冲(double buffering)”效应,否则会在文件系统缓存与InnoDB缓存间形成2个副本(copy). 
    假设不使用硬件RAID控制器,或者使用SAN存储时, O_DIRECT 可能会导致性能下降.​​ ​​ 和 ​ ​​ 具体地说明了这一点.
  • —— 默认值为 1. 在SSD存储上应设置为0(禁用) ,由于使用顺序IO没有不论什么性能收益. 在使用RAID的某些硬件上也应该禁用此设置,由于逻辑上连续的块在物理磁盘上并不能保证也是连续的.
  • —— 这些设置会影响InnoDB每秒在后台运行多少操作. 在 ​​ 里我描写叙述了大多数写IO(除了写InnoDB日志)是后台操作的. 假设你深度了解硬件性能(如每秒能够运行多少次IO操作),则使用这些功能是非常可取的,而不是让它闲着.

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

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

将这两个值设置得太大可能会存在某些风险,你肯定不希望后台操作妨碍了前台任务IO操作的性能. 过去的经验表明,将这两个值设置的太高,InnoDB持有的内部锁会导致性能降低(按我了 - 默认值为 1024. 这是mysql 5.6中引入的一个新选项. Mark Callaghan 简单来说,假设增大了 innodb_io_capacity 值, 应该同一时候添加 innodb_lru_scan_depth.

复制(Replication)

假如服务器要支持主从复制,或按时间点恢复,在这样的情况下,我们须要:

  • —— 启用二进制日志. 默认情况下二进制日志不是事故安全的(not crash safe),但如同我 ​​, 我建议大多数用户应该以稳定性为目标. 在这样的情况下,你还须要启用: ​​
  • — 默认旧日志会一直保留. 我推荐设置为 1-10 天. 保存更长的时间并没有太多用处,由于从备份中恢复会快得多.
  • ​​ —— 在一个主从复制体系(replication topology )中的全部服务器都必须设置唯一的 server-id.
  • —— 改动为基于行的复制. 我近期写的还有一篇 ,里面叙述了我真的非常喜欢它的原因,由于它能够通过降低资源锁定提高性能. 此外还须要启用两个附加设置:  ​​ ​ and  ​​

其它配置(Misc)

  • 将时区设置为格林尼治时间. 越来越多的系统管理员建议将全部服务器都设置为 格林尼治时间(GMT). 我个人非常喜欢这点,由于如今差点儿全部的业务都是全球化的. 设置为你本地的时区似乎是有点武断的.
  • 如之前的 文章所讲述的 ,utf8 编码对新应用来说是更好的默认选项. 您还能够设置 以忽略应用程序想要设置的其它字符集(character-set).
  • —— MySQL默认对不规范的数据非常宽容,而且会静默地截断数据. 在我 ​​ 我提到新应用程序最好设置为： STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,

NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,

NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,

NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY.

  • —— 禁用反向域名解析. DNS解析在某些系统上可能有点慢/不稳定,所以假设不须要基于主机名的授权,我建议避免这样的解析.
  • :“[这个功能]提供了没有实际意义的暴力訪问攻击保护”. 其实当设置skip-name-resolve 时, max_connect_errors 甚至不起作用(见上一段所述).

防火墙是更合适的解决方式,通常我将3306port屏蔽,无论是公网的还是内网的port,仅仅有特定的应用程序能够訪问和连接到MySQL. 

我一般会设置 max_connect_errors=100000, 这样我能够避免不论什么“双重配置”,保证它不会碍事.

  • ——默认值是151. 我看到非常多用户将他设置得比較大,大多在 300 ~ 1000之间.

通常不可避免地这个值会被设置得更大,但让我有点紧张的是, 16核的机器在IO堵塞的情况下也仅仅有大约 2x~10x 的连接运行能力. 

你可能希望,很多打开的连接都是空暇并休眠的. 但假设他们都处于活跃状态的话,可能会创建大量新的线程(thread-thrash).

假设条件同意,能够为应用程序配置优化数据库连接池(connection-pools)来解决问题,而不是打开并保持大量连接; 

当然那些不使用连接池(non-pooled ), 迅速打开,运行任务后又尽可能快地关闭连接的应用也是可行的. 

从5.5開始的还有一种解决方式(在MySQL社区版和企业版之间有一些差异) 是使用 ​​.


总结(Conclusion)

假设MySQL服务器的配置为:

  • 64GB物理内存
  • 硬件RAID控制器(假设每秒IO可达 2000 IOPS)
  • 须要主从复制(Replication)
  • 新的应用(eg. 非遗留系统)
  • 有防火墙保护
  • 不须要基于域名(hostnames,主机名)的授权
  • 全球化应用,并不想固定在某一时区.
  • 想要程序

则配置可能例如以下所看到的:

# 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
sql-mode="STRICT_TRANS_TABLES,
 ERROR_FOR_DIVISION_BY_ZERO,
 NO_AUTO_CREATE_USER,
 NO_AUTO_VALUE_ON_ZERO,
 NO_ENGINE_SUBSTITUTION,
 NO_ZERO_DATE,
 NO_ZERO_IN_DATE,
 ONLY_FULL_GROUP_BY"
skip-name_resolve
max-connect-errors=100000
max-connections=500

# Unique to this machine
server-id=123