安装 MySQL 后，需要调整的 10 个性能配置项（参数优化）

注意：这篇博文的更新版本在这儿，MySQL 5.7 适用！

翻译原文：http://www.cnblogs.com/glon/p/6484912.html
英文原文：https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/

在本文中，我们将探讨在安装好 MySQL 之后，可以进行调整的影响性能的前 10 个配置选项。

当我们作为一名 MySQL 性能审计人员被录用时，他们（公司）会希望我们重新检查 MySQL 的配置文件，并且给出一些改进的建议。很多人感到很惊讶，因为在大多数情况下，我们对已安装的实例仅仅对少数的 MySQL 性能配置项建议进行调整，即使这个实例已经启用了几百个选项。本文的目的是给出一份列举了一些关键性配置项的清单。

几年前，我们曾经在这篇博文中给出了一些建议，但从那以后，MySQL 有了很大的改变。

写在开始之前

即便是经验丰富的人也会失误，也引起很多麻烦。所以在盲目的应用本文推荐的配置项之前，请牢记下面的几项：

  1. 一次只更改一个配置项！这是检验本次更改是否有利的途径。
  2. 大多数配置项可以在运行时使用 SET GLOBAL 命令来修改。这种方式非常方便，并且如果修改后出现问题，还能马上恢复原设置。但到最后，仍然需要把这个改变写到配置文件中，使之永久生效。
  3. 一个配置的调整即使重启了 MySQL 实例也没有生效？那么你是否使用了正确配置文件？你是否把这个选项写到了正确的节下面？（本文的所有选项都归属于 [mysqld] 节）
  4. 服务器在配置调整之后启动失败：你是否使用了正确的单位？例如， innodb_buffer_pool_size 的单位是 byte，而 max_connection 是没有单位的。
  5. 同一个配置文件里不要出现重复的配置项。如果你想追踪更改历史，请使用版本控制器。
  6. 别做幼稚的运算，如“我的新服务器的 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 日志），这样可以提供充足的写空间。如果你知道你的应用是频繁写入的，并且你使用的 MySQL 版本是 MySQL 5.6，你可以设置 innodb_log_file_size = 4G。

  • 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, 或者重建表的时候，会回收这个表空间。在一些高级特性，如压缩的时候也需要开启使用独立表空间。然而这个选项却不能带来性能的提升。你不想使用独立表空间的一个主要场景是：有很多的表（例如：10000 以上张表）。

在 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（查询缓存）是一个众所周知的瓶颈位，即使在并发量不高的时候也会出现。最好的选择是从一开始就禁用它，通过设置 query_cache_size = 0 (MySQL 5.6 中现在已经默认禁用)，并通过其它途径去提高读查询：合适的索引，增加从库去分散读压力，或者使用一个额外的缓存（例如 memcache 或者 redis）。如果你的 MySQL 已经开启了查询缓存，并且没有发现有任何错误，开启查询缓存可能是有利的，如果要禁用它，就需要谨慎了。

  • log_bin：如果要让一个节点做为复制关系中的主节点，启用二进制日志（binary log）是必须的。这样的话，同时需要设置全局唯一的 server_id。 对于单节点，在希望做基于时间点的恢复的时候，开启这个选项也是很有用的：恢复最新的备份和应用二进制日志。二进制日志一旦创建，会被永久保存。所以如果不想耗尽磁盘空间，应该使用 PURGE BINARY LOGS 清理旧的二进制日志文件，或者设置 expire_logs_days 选项指定多少天之后，自动清理过期的二进制日志。

记录二进制日志不是没有开销的。所以，例如是一个复制关系中的从节点，建议禁用二进制日志。

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

结论

当然，根据你的负载和硬件的实际情况，还有其他的设置能够起到调优的作用：例如在小内存、高速磁盘，高并发，写密集型的负载下，需要特定的调优。不过本文的目的是给出几个 MySQL 的性能调优配置项，让你可以快速得到一个稳健的配置文件，而不用花费大量的时间去调整一些没那么重要的 MySQL 配置项，或者去查阅官方文档来找出哪些配置项对你而言是至关重要的。