MySQL 服务器调优

记录慢速查询

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

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

您能够配置 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. 显示打开表的活动

mysql> SHOW STATUS LIKE 'open%tables'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Open_tables | 5000 | | Opened_tables | 195 | +---------------+-------+ 2 rows in set (0.00 sec)

 

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

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

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

清单 5. 显示线程使用统计信息

mysql> SHOW STATUS LIKE 'threads%'; +-------------------+--------+ | Variable_name | Value | +-------------------+--------+ | Threads_cached | 27 | | Threads_connected | 15 | | Threads_created | 838610 | | Threads_running | 3 | +-------------------+--------+ 4 rows in set (0.00 sec)

 

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

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

清单 6. 肯定关键字效率

mysql> show status like '%key_read%'; +-------------------+-----------+ | Variable_name | Value | +-------------------+-----------+ | Key_read_requests | 163554268 | | Key_reads | 98247 | +-------------------+-----------+ 2 rows in set (0.00 sec)

 

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

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

清单 7. 肯定临时表的使用

mysql> SHOW STATUS LIKE 'created_tmp%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 30660 | | Created_tmp_files | 2 | | Created_tmp_tables | 32912 | +-------------------------+-------+ 3 rows in set (0.00 sec)

 

每次使用临时表都会增大 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 给出了一些与排序相关的状态计数器信息。

清单 8. 显示排序统计信息

mysql> SHOW STATUS LIKE "sort%"; +-------------------+---------+ | Variable_name | Value | +-------------------+---------+ | Sort_merge_passes | 1 | | Sort_range | 79192 | | Sort_rows | 2066532 | | Sort_scan | 44006 | +-------------------+---------+ 4 rows in set (0.00 sec)

 

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

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

清单 9. 肯定表扫描比率

mysql> SHOW STATUS LIKE "com_select"; +---------------+--------+ | Variable_name | Value | +---------------+--------+ | Com_select | 318243 | +---------------+--------+ 1 row in set (0.00 sec) mysql> SHOW STATUS LIKE "handler_read_rnd_next"; +-----------------------+-----------+ | Variable_name | Value | +-----------------------+-----------+ | Handler_read_rnd_next | 165959471 | +-----------------------+-----------+ 1 row in set (0.00 sec)

 

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