安装MySQL后，须要调整的10个性能配置项

本文翻译自 Percona 官方博客，适用于 MySQL 5.6 及 5.7 版本。
做者：Stephane Combaudon
原文：
https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/

在本博客中，咱们将和你们讨论下 MySQL 数据库安装后，建议调整的十个性能设置参数。

一般状况下，当咱们须要进行 MySQL 性能审计时，咱们将审查 MySQL 配置并提出改进建议。在大多数状况下，咱们只建议安装后更改一些核心的 MySQL 性能调优参数，即便有数百个选项可用。这篇文章的目的是给你列出一些最关键的参数设置，并告诉你如何去调整它们。

在开始调整以前

即便是有经验的人也会犯一些会形成许多麻烦的错误。所以，在应用本文推荐的配置项以前，请牢记下面的几项：

• 每次更改一个设置！这是验证设置是否有效的惟一方法。
• 大多数配置项能够在运行时使用 SET GLOBAL 命令来修改。这种方式很是方便，而且若是修改后出现问题，还能立刻恢复原设置。但到最后，仍然须要把这个改变写到配置文件中，使之永久生效。
• 有时候即便 MySQL 重启后，配置文件中的参数也不生效。这时候你须要考虑：你使用正确的配置文件了吗？你把这个参数放在正确的地方了吗？（在这篇文章中的全部配置都属于[mysqld]部分）
• 如在更改配置后数据库没法启动，须要检查是否使用正确的单位？例如， innodb_buffer_pool_size 的单位是 byte，而 max_connection 是没有单位的。
• 在配置文件中不容许重复设置。若是要跟踪配置的更改，请使用版本控制。
• 不要作天真的数学算法，好比“个人新服务器的 RAM 是旧的 2 倍，所以能够把全部的配置项的值都设置成以前的 2 倍”。

基础设置

这里主要讲解 3 个很是重要的 MySQL 性能配置项，你应该常常会看到这些参数。若是你没有调整，极可能会遇到问题。

innodb_buffer_pool_size：

这是任何使用 InnoDB 存储引擎的 MySQL 在安装后第一个应该要查看的配置。Buffer pool 是用来缓存数据和索引的，应该分配尽量大的内存，以确保在进行大多数读取操做时是读内存而不是读磁盘。典型的设置值为 5-6GB(8GB RAM)，20-25G(32GB RAM)，100-120GB(128GB RAM)。

innodb_log_file_size：

这个选项是设置 redo 日志（重作日志）的大小。redo 日志是用来确保写入的数据可以快速地写入，而且持久化，还能够用于崩溃恢复(crash recovery)。MySQL 5.1 以前，这个选项很难去进行调整，由于你既想要加大 redo 日志来提升性能，又想要减少 redo 日志来进行快速的崩溃恢复。幸运的是，自 MySQL 5.5 以后，崩溃恢复的性能有了很大的提升，如今你能够拥有快速写入性能的同时，还能知足快速崩溃恢复。一直到 MySQL 5.5，redo 日志的总大小被限制在 4GB (默认有 2 个日志文件)。这个在 MySQL 5.6 中被增长了。

启动的时候设置 innodb_log_file_size = 512M（也就是 1GB 大小的 redo 日志），这样能够提供充足的写空间。若是你知道你的应用是频繁写入的，还能够再增大些。

max_connections：

若是你常常遇到 "Too many connections" 的错误，是由于 max_connections 过小了。这个错误很常见到，由于应用程序没有正确地关闭与数据库的链接，你须要设置链接数为比默认 151 更大的值。max_connections 设置太高（如 1000 或更高）的一个主要缺点是当服务器运行 1000 个或者更多的事务时，会响应缓慢甚至没有响应。在应用程序端使用链接池或者在 MySQL 端使用线程池有助于解决这个问题。

InnoDB 设置

从 MySQL 5.5 开始，InnoDB 成为了默认的存储引擎，而且它的使用频率比其余存储引擎的要多得多。这就是要认真配置它的缘由。

innodb_file_per_table：

这个配置项会决定 InnoDB 是使用共享表空间(innodb_file_per_table = OFF) 来存储数据和索引，仍是为每一个表使用一个单独的 ibd 文件(innodb_file_per_table= ON)。对每一个表使用一个文件的方式，在 drop, truncate, 或者重建表的时候，会回收这个表空间。在一些高级特性，如压缩的时候也须要开启使用独立表空间。然而这个选项却不能带来性能的提高。

在 MySQL 5.6 及以后的版本中，这个配置项是默认开启的，所以多数状况下，你无需操做。对于早期的 MySQL 版本，须要在启动前把它设置成 ON ，由于它只对新建立的表有影响。

innodb_flush_log_at_trx_commit：

默认值为 1，表示 InnoDB 彻底支持 ACID 特性。例如在在一个主节点上，你主要关注数据安全性，这是最好的设置值。然而它会对速度缓慢的磁盘系统形成很大的开销，由于每次将改变刷新到 redo 日志的时候，都须要额外的 fsync 操做。设置为 2，可靠性会差一点，由于已提交的事务只会 1 秒钟刷新一次到 redo 日志，但在某些状况下，对一个主节点而言，这仍然是能够接受的，并且对于复制关系的从库来讲，这是一个很好的值。设置为 0，速度更快，可是在遇到崩溃的时候极可能会丢失一些数据，这只对从库是一个好的设置值。

innodb_flush_method：

这个设置项决定了数据和日志刷新到磁盘的方式。当服务器硬件有 RAID 控制器、断电保护、采起 write-back 缓存机制的时候，最经常使用的值是 O_DIRECT；其余大多数场景使用默认值 fdatasync。sysbench 是一个帮助你在这两个值之间作出选择好工具。

innodb_log_buffer_size：

这个设置项用来设置缓存尚未提交的事务的缓冲区的大小。默认值(1MB) 通常是够用的，但一旦事务之中带有大 blob/text 字段，这个缓冲区会被很快填满，并引发额外的 I/O 负载。看看 innodb_log_waits 这个状态变量的值，若是不是 0 的话，须要增长 innodb_log_buffer_size。

其余设置

query_cache_size：

你们都知道查询缓存是一个瓶颈，即便在并发量不高的时候也会出现。 最好的设置就是在第一天使用时就禁用查询缓存(query_cache_size = 0)  ，该选项在 MySQL 5.6 后是默认禁用的，咱们能够经过其余途径来提升查询速度: 设计好的索引，增加读写分离，或者使用额外的缓存 (memcache or redis for instance)。若是您的 MySQL 已经启用了查询缓存而且从没有发现过问题， 那么查询缓存多是对你有益的，这个时候若是你想禁用它的时候应该当心操做。

log_bin：

若是要让一个节点作为复制关系中的主节点，启用二进制日志（binary log）是必须的。同时须要设置全局惟一的 server_id。 若是是单实例数据库，若是你要将数据恢复到以前时间点（使用最新的备份restore，而后使用binlog进行recover），那么就须要二进制日志。二进制日志一旦建立，会被永久保存，因此若是不想耗尽磁盘空间，应该使用 PURGE BINARY LOGS 清理旧的二进制日志文件，或者设置 expire_logs_days 选项指定多少天以后，自动清理过时的二进制日志。

二进制文件记录是须要消耗资源的，所以在主从复制环境中，若是备库不须要 Binlog ，就能够禁用掉。

skip_name_resolve：

当一个客户端链接上来的时候，服务端会执行主机名解释操做，当 DNS 很慢时，创建的链接也会很慢。所以建议在启动的时候设置 skip-name-resolve 来禁用 DNS 查找。惟一的局限是 GRANT 语句仅且仅能使用 IP 地址，因此，在已有系统中添加这个选项时须要格外当心。

结论

固然，根据你的负载和硬件的实际状况，还有其余的设置可以起到调优的做用：例如在小内存、高速磁盘，高并发，写密集型的负载下，须要特定的调优。不过本文的目的是给出几个 MySQL 的性能调优配置项，让你快速配置一个合理的 MySQL 配置文件，而且了解哪些参数对你很重要，而不须要花费大量时候去阅读官方文档。