本文翻译自 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 配置文件，并且理解哪些参数对你很重要，而不须要破费大量时候去浏览官网文档。