本文来自Percona官方博客，适用于MySQL 5.6和5.7版。 作者： Stephane Combaudon原文： https://www.percona.com/blog/2014/01/28/10-MySQL-performance-tuning-settings-a ftt
本博客介绍了建议在安装MySQL数据库后进行协调的10个性能设置参数。
通常，如果需要MySQL性能审计，请检查MySQL配置并提出改进建议。 大多数情况下，建议在安装后更改几个核心的MySQL性能调优参数。 即使有数百个选项可用。 本文的目的是给出最重要的参数设置，并告诉你如何调整它们。
在开始调整之前
即使是有经验的人也会犯很多引起麻烦的错误。 因此，在应用本文中建议的配置项目之前，请注意以下事项：请一次更改一个设定。 这是验证设置是否有效的唯一方法。 大多数设置都可以在运行时使用SET GLOBAL命令进行更改。 这种方式非常有用，如果修改后出现问题，可以立即恢复到原始设置。 但是，最后必须将此更改写入配置文件，使其永久生效。 重新启动MySQL可能不会启用配置文件中的参数。 此时，您是否使用了正确的配置文件？ 你把这个参数放在正确的地方了吗？ (本文的所有配置都属于[mysqld]部分)如果更改配置后数据库未启动，则必须验证是否使用了正确的单位。 例如，innodb_buffer_pool_size的单位为byte，max_connection没有单位。 配置式不允许重复设置。 如果要跟踪配置更改，请使用版本控制。 不要做天真的数学算法。 例如，“我的新服务器的RAM是旧的两倍，所以所有配置项的值都可以设置为以前的两倍”。
基础设置
此处主要介绍三个非常重要的MySQL性能配置项。 这些参数应该很常见。 如果不进行调整，发生问题的可能性很高。innodb_buffer_pool_size :
这是使用InnoDB存储引擎的MySQL在安装后必须首先显示的配置。 Buffer pool用于缓存数据和索引，并且必须分配尽可能大的内存，以便大多数读取操作使用读取内存而不是磁盘。 典型的设置为5-6GB(8GBram (，20-25g )、32GBram )、100-120GB )和128GBram )。
innodb_log_file_size :
此选项设置重做日志(重做日志)的大小。 重做日志用于确保写入的数据快速写入并持久化。 它还可用于“故障恢复”。 在MySQL 5.1之前，很难调整此选项，因为您希望增加重做日志以提高性能，减少重做日志以实现快速崩溃恢复。 幸运的是，从MySQL 5.5开始，崩溃恢复性能有了很大提高。 现在，您可以满足快速崩溃恢复，同时保持高速写入性能。 到MySQL 5.5为止，重做日志的总大小限制为4GB。 默认情况下有两个日志文件。 这是在MySQL 5.6中添加的。
启动时设置innodb_log_file_size=512M，即1GB大小的重做日志，可以提供足够的写入空间。 如果你知道你的APP应用程序经常被写入，你可以做得更大。
max_connections :
你经常遇到“Too many connections”的错误是因为max_connections太小了。 这个错误很常见。 由于APP应用程序未正确关闭与数据库的连接，因此连接数必须设置为大于缺省值151。 max_connections设置过高(如1000或更高)的一个主要缺点是，如果服务器运行1000或更高的事务，则响应会变慢或没有响应。 可以通过在APP应用程序端使用连接池，或在MySQL端使用线程池来解决此问题。
从
InnoDB 设置
MySQL5.5开始，InnoDB成为默认的存储引擎，使用频率远远高于其他存储引擎。 这就是认真安排它的理由。 lign: start">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_xqdsmt：
如果要让一个节点做为复制关系中的主节点，启用二进制日志（xqdsmtary log）是必须的。同时需要设置全局唯一的 server_id。 如果是单实例数据库，如果你要将数据恢复到之前时间点（使用最新的备份restore，然后使用xqdsmtlog进行recover），那么就需要二进制日志。二进制日志一旦创建，会被永久保存，所以如果不想耗尽磁盘空间，应该使用 PURGE BINARY LOGS 清理旧的二进制日志文件，或者设置 expire_logs_days 选项指定多少天之后，自动清理过期的二进制日志。
二进制文件记录是需要消耗资源的，因此在主从复制环境中，如果备库不需要 Binlog ，就可以禁用掉。
skip_name_resolve：
当一个客户端连接上来的时候，服务端会执行主机名解释操作，当 DNS 很慢时，建立的连接也会很慢。因此建议在启动的时候设置 skip-name-resolve 来禁用 DNS 查找。唯一的局限是 GRANT 语句仅且仅能使用 IP 地址，所以，在已有系统中添加这个选项时需要格外小心。
结论
当然，根据你的负载和硬件的实际情况，还有其他的设置能够起到调优的作用：例如在小内存、高速磁盘，高并发，写密集型的负载下，需要特定的调优。不过本文的目的是给出几个 MySQL 的性能调优配置项，让你快速配置一个合理的 MySQL 配置文件，并且了解哪些参数对你很重要，而不需要花费大量时候去阅读官方文档。