MySQL 服务器调优

时间 2019-12-20

原文原文链接

利用服务器的几个调优技巧，让 MySQL 服务器飞速运行
现在，开发人员不断地开发和部署使用 LAMP（Linux®、Apache、MySQL 和 PHP/Perl）架构的应用程序。可是，服务器管理员经常对应用程序自己没有什么控制能力，由于应用程序是别人编写的。这份共三部分的系列文章将讨论许多服务器配置问题，这些配置会影响应用程序的性能。本文是本系列文章的第三部分，也是最后一部分，将重点讨论为实现最高效率而对数据库层进行的调优。html

关于 MySQL 调优mysql

有 3 种方法能够加快 MySQL 服务器的运行速度，效率从低到高依次为：
替换有问题的硬件。
对 MySQL 进程的设置进行调优。
对查询进行优化。sql

替换有问题的硬件一般是咱们的第一考虑，主要缘由是数据库会占用大量资源。不过这种解决方案也就仅限于此了。实际上，您一般可让中央处理器（CPU）或磁盘速度加倍，也可让内存增大 4 到 8 倍。数据库

第二种方法是对 MySQL 服务器（也称为 mysqld）进行调优。对这个进程进行调优意味着适当地分配内存，并让 mysqld 了解将会承受何种类型的负载。加快磁盘运行速度不如减小所需的磁盘访问次数。相似地，确保 MySQL 进程正确操做就意味着它花费在服务查询上的时间要多于花费在处理后台任务（如处理临时磁盘表或打开和关闭文件）上的时间。对 mysqld 进行调优是本文的重点。缓存

最好的方法是确保查询已经进行了优化。这意味着对表应用了适当的索引，查询是按照能够充分利用 MySQL 功能的方式来编写的。尽管本文并无包含查询调优方面的内容（不少著做中已经针对这个主题进行了探讨），不过它会配置 mysqld 来报告可能须要进行调优的查询。安全

虽然已经为这些任务指派了次序，可是仍然要注意硬件和 mysqld 的设置以利于适当地调优查询。机器速度慢也就罢了，我曾经见过速度很快的机器在运行设计良好的查询时因为负载太重而失败，由于 mysqld 被大量繁忙的工做所占用而不能服务查询。服务器

记录慢速查询架构

在一个 SQL 服务器中，数据表都是保存在磁盘上的。索引为服务器提供了一种在表中查找特定数据行的方法，而不用搜索整个表。当必需要搜索整个表时，就称为表扫描。一般来讲，您可能只但愿得到表中数据的一个子集，所以全表扫描会浪费大量的磁盘 I/O，所以也就会浪费大量时间。当必须对数据进行链接时，这个问题就更加复杂了，由于必需要对链接两端的多行数据进行比较。less

固然，表扫描并不老是会带来问题；有时读取整个表反而会比从中挑选出一部分数据更加有效（服务器进程中查询规划器用来做出这些决定）。若是索引的使用效率很低，或者根本就不能使用索引，则会减慢查询速度，并且随着服务器上的负载和表大小的增长，这个问题会变得更加显著。执行时间超过给定时间范围的查询就称为慢速查询。ide

您能够配置 mysqld 将这些慢速查询记录到适当命名的慢速查询日志中。管理员而后会查看这个日志来帮助他们肯定应用程序中有哪些部分须要进一步调查。清单 1 给出了要启用慢速查询日志须要在 my.cnf 中所作的配置。

清单 1. 启用 MySQL 慢速查询日志

[mysqld] ; enable the slow query log, default 10 seconds log-slow-queries ; log queries taking longer than 5 seconds long_query_time = 5 ; log queries that don’t use indexes even if they take less than long_query_time ; MySQL 4.1 and newer only log-queries-not-using-indexes

这三个设置一块儿使用，能够记录执行时间超过 5 秒和没有使用索引的查询。请注意有关 log-queries-not-using-indexes 的警告：您必须使用 MySQL 4.1 或更高版本。慢速查询日志都保存在 MySQL 数据目录中，名为 hostname-slow.log。若是但愿使用一个不一样的名字或路径，能够在 my.cnf 中使用 log-slow-queries = /new/path/to/file 实现此目的。

阅读慢速查询日志最好是经过 mysqldumpslow 命令进行。指定日志文件的路径，就能够看到一个慢速查询的排序后的列表，而且还显示了它们在日志文件中出现的次数。一个很是有用的特性是 mysqldumpslow 在比较结果以前，会删除任何用户指定的数据，所以对同一个查询的不一样调用被计为一次；这能够帮助找出须要工做量最多的查询。

对查询进行缓存

不少 LAMP 应用程序都严重依赖于数据库，但却会反复执行相同的查询。每次执行查询时，数据库都必需要执行相同的工做 —— 对查询进行分析，肯定如何执行查询，从磁盘中加载信息，而后将结果返回给客户机。MySQL 有一个特性称为查询缓存，它将（后面会用到的）查询结果保存在内存中。在不少状况下，这会极大地提升性能。不过，问题是查询缓存在默认状况下是禁用的。

将 query_cache_size = 32M 添加到 /etc/my.conf 中能够启用 32MB 的查询缓存。

监视查询缓存

在启用查询缓存以后，重要的是要理解它是否获得了有效的使用。MySQL 有几个能够查看的变量，能够用来了解缓存中的状况。清单 2 给出了缓存的状态。

清单 2. 显示查询缓存的统计信息
mysql> SHOW STATUS LIKE ‘qcache%’;
+————————-+————+
| Variable_name           | Value      |
+————————-+————+
| Qcache_free_blocks      | 5216       |
| Qcache_free_memory      | 14640664   |
| Qcache_hits             | 2581646882 |
| Qcache_inserts          | 360210964 |
| Qcache_lowmem_prunes    | 281680433 |
| Qcache_not_cached       | 79740667   |
| Qcache_queries_in_cache | 16927      |
| Qcache_total_blocks     | 47042      |
+————————-+————+
8 rows in set (0.00 sec)

这些项的解释如表 1 所示。

表 1. MySQL 查询缓存变量变量名说明
Qcache_free_blocks 缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理，从而获得一个空闲块。
Qcache_free_memory 缓存中的空闲内存。
Qcache_hits 每次查询在缓存中命中时就增大。
Qcache_inserts 每次插入一个查询时就增大。命中次数除以插入次数就是不中比率；用 1 减去这个值就是命中率。在上面这个例子中，大约有 87% 的查询都在缓存中命中。
Qcache_lowmem_prunes 缓存出现内存不足而且必需要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；若是这个数字在不断增加，就表示可能碎片很是严重，或者内存不多。（上面的 free_blocks 和 free_memory 能够告诉您属于哪一种状况）。
Qcache_not_cached 不适合进行缓存的查询的数量，一般是因为这些查询不是 SELECT 语句。
Qcache_queries_in_cache 当前缓存的查询（和响应）的数量。
Qcache_total_blocks 缓存中块的数量。
一般，间隔几秒显示这些变量就能够看出区别，这能够帮助肯定缓存是否正在有效地使用。运行 FLUSH STATUS 能够重置一些计数器，若是服务器已经运行了一段时间，这会很是有帮助。

使用很是大的查询缓存，指望能够缓存全部东西，这种想法很是诱人。因为 mysqld 必需要对缓存进行维护，例如当内存变得很低时执行剪除，所以服务器可能会在试图管理缓存时而陷入困境。做为一条规则，若是 FLUSH QUERY CACHE 占用了很长时间，那就说明缓存太大了。

强制限制

您能够在 mysqld 中强制一些限制来确保系统负载不会致使资源耗尽的状况出现。清单 3 给出了 my.cnf 中与资源有关的一些重要设置。

清单 3. MySQL 资源设置
set-variable=max_connections=500
set-variable=wait_timeout=10
max_connect_errors = 100

链接最大个数是在第一行中进行管理的。与 Apache 中的 MaxClients 相似，其想法是确保只创建服务容许数目的链接。要肯定服务器上目前创建过的最大链接数，请执行 SHOW STATUS LIKE ‘max_used_connections’。

第 2 行告诉 mysqld 终止全部空闲时间超过 10 秒的链接。在 LAMP 应用程序中，链接数据库的时间一般就是 Web 服务器处理请求所花费的时间。有时候，若是负载太重，链接会挂起，而且会占用链接表空间。若是有多个交互用户或使用了到数据库的持久链接，那么将这个值设低一点并不可取！

最后一行是一个安全的方法。若是一个主机在链接到服务器时有问题，并重试不少次后放弃，那么这个主机就会被锁定，直到 FLUSH HOSTS 以后才能运行。默认状况下，10 次失败就足以致使锁定了。将这个值修改成 100 会给服务器足够的时间来从问题中恢复。若是重试 100 次都没法创建链接，那么使用再高的值也不会有太多帮助，可能它根本就没法链接。

缓冲区和缓存

MySQL 支持超过 100 个的可调节设置；可是幸运的是，掌握少数几个就能够知足大部分须要。查找这些设置的正确值能够经过 SHOW STATUS 命令查看状态变量，从中能够肯定 mysqld 的运做状况是否符合咱们的预期。给缓冲区和缓存分配的内存不能超过系统中的现有内存，所以调优一般都须要进行一些妥协。

MySQL 可调节设置能够应用于整个 mysqld 进程，也能够应用于单个客户机会话。

服务器端的设置

每一个表均可以表示为磁盘上的一个文件，必须先打开，后读取。为了加快从文件中读取数据的过程，mysqld 对这些打开文件进行了缓存，其最大数目由 /etc/mysqld.conf 中的 table_cache 指定。清单 4 给出了显示与打开表有关的活动的方式。

清单 4 说明目前有 5,000 个表是打开的，有 195 个表须要打开，由于如今缓存中已经没有可用文件描述符了（因为统计信息在前面已经清除了，所以可能会存在 5,000 个打开表中只有 195 个打开记录的状况）。若是 Opened_tables 随着从新运行 SHOW STATUS 命令快速增长，就说明缓存命中率不够。若是 Open_tables 比 table_cache 设置小不少，就说明该值太大了（不过有空间能够增加总不是什么坏事）。例如，使用 table_cache = 5000 能够调整表的缓存。

与表的缓存相似，对于线程来讲也有一个缓存。 mysqld 在接收链接时会根据须要生成线程。在一个链接变化很快的繁忙服务器上，对线程进行缓存便于之后使用能够加快最初的链接。

清单 5 显示如何肯定是否缓存了足够的线程。

此处重要的值是 Threads_created，每次 mysqld 须要建立一个新线程时，这个值都会增长。若是这个数字在连续执行 SHOW STATUS 命令时快速增长，就应该尝试增大线程缓存。例如，能够在 my.cnf 中使用 thread_cache = 40 来实现此目的。

关键字缓冲区保存了 MyISAM 表的索引块。理想状况下，对于这些块的请求应该来自于内存，而不是来自于磁盘。清单 6 显示了如何肯定有多少块是从磁盘中读取的，以及有多少块是从内存中读取的。

Key_reads 表明命中磁盘的请求个数， Key_read_requests 是总数。命中磁盘的读请求数除以读请求总数就是不中比率 —— 在本例中每 1,000 个请求，大约有 0.6 个没有命中内存。若是每 1,000 个请求中命中磁盘的数目超过 1 个，就应该考虑增大关键字缓冲区了。例如，key_buffer = 384M 会将缓冲区设置为 384MB。

临时表能够在更高级的查询中使用，其中数据在进一步进行处理（例如 GROUP BY 字句）以前，都必须先保存到临时表中；理想状况下，在内存中建立临时表。可是若是临时表变得太大，就须要写入磁盘中。清单 7 给出了与临时表建立有关的统计信息。

每次使用临时表都会增大 Created_tmp_tables；基于磁盘的表也会增大 Created_tmp_disk_tables。对于这个比率，并无什么严格的规则，由于这依赖于所涉及的查询。长时间观察 Created_tmp_disk_tables 会显示所建立的磁盘表的比率，您能够肯定设置的效率。 tmp_table_size 和 max_heap_table_size 均可以控制临时表的最大大小，所以请确保在 my.cnf 中对这两个值都进行了设置。

每一个会话的设置

下面这些设置针对于每一个会话。在设置这些数字时要十分谨慎，由于它们在乘以可能存在的链接数时候，这些选项表示大量的内存！您能够经过代码修改会话中的这些数字，或者在 my.cnf 中为全部会话修改这些设置。

当 MySQL 必需要进行排序时，就会在从磁盘上读取数据时分配一个排序缓冲区来存放这些数据行。若是要排序的数据太大，那么数据就必须保存到磁盘上的临时文件中，并再次进行排序。若是 sort_merge_passes 状态变量很大，这就指示了磁盘的活动状况。清单 8 给出了一些与排序相关的状态计数器信息。

若是 sort_merge_passes 很大，就表示须要注意 sort_buffer_size。例如， sort_buffer_size = 4M 将排序缓冲区设置为 4MB。

MySQL 也会分配一些内存来读取表。理想状况下，索引提供了足够多的信息，能够只读入所须要的行，可是有时候查询（设计不佳或数据本性使然）须要读取表中大量数据。要理解这种行为，须要知道运行了多少个 SELECT 语句，以及须要读取表中的下一行数据的次数（而不是经过索引直接访问）。实现这种功能的命令如清单 9 所示。

Handler_read_rnd_next / Com_select 得出了表扫描比率 —— 在本例中是 521:1。若是该值超过 4000，就应该查看 read_buffer_size，例如 read_buffer_size = 4M。若是这个数字超过了 8M，就应该与开发人员讨论一下对这些查询进行调优了！

3 个必不可少的工具

尽管在了解具体设置时，SHOW STATUS 命令会很是有用，可是您还须要一些工具来解释 mysqld 所提供的大量数据。我发现有 3 个工具是必不可少的；在参考资料一节中您能够找到相应的连接。

大部分系统管理员都很是熟悉 top 命令，它为任务所消耗的 CPU 和内存提供了一个不断更新的视图。 mytop 对 top 进行了仿真；它为全部链接上的客户机以及它们正在运行的查询提供了一个视图。mytop 还提供了一个有关关键字缓冲区和查询缓存效率的实时数据和历史数据，以及有关正在运行的查询的统计信息。这是一个颇有用的工具，能够查看系统中（好比 10 秒钟以内）的情况，您能够得到有关服务器健康信息的视图，并显示致使问题的任何链接。

mysqlard 是一个链接到 MySQL 服务器上的守护程序，负责每 5 分钟搜集一次数据，并将它们存储到后台的一个 Round Robin Database 中。有一个 Web 页面会显示这些数据，例如表缓存的使用状况、关键字效率、链接上的客户机以及临时表的使用状况。尽管 mytop 提供了服务器健康信息的快照，可是 mysqlard 则提供了长期的健康信息。做为奖励，mysqlard 使用本身搜集到的一些信息针对如何对服务器进行调优给出一些建议。

搜集 SHOW STATUS 信息的另一个工具是 mysqlreport。其报告要远比 mysqlard 更加复杂，由于须要对服务器的每一个方面都进行分析。这是对服务器进行调优的一个很是好的工具，由于它对状态变量进行适当计算来帮助肯定须要修正哪些问题。

文章转自：http://hi.baidu.com/%CA%AB%D5%B9/blog/item/42dd2e344abe473d5ab5f547.html