优化MySQL,提高MySQL命中率

MySQL优化，启动MySQL缓存机制，提高MySQL命中率。

修改MySQL配置文件：主要是配置[mysqld]后面的内容。
1，优化远程链接速度。
在[mysqld]下面添加skip-name-resolve

skip-name-resolve

禁用DNS解析，提高链接速度。不过，这样的话就不能在MySQL的受权表中使用主机名了而只能用ip格式。
2，设置链接数，mysql默认的链接数是100，比较少，能够增长MySQL链接数。
[mysqld]模块下面添加

max_connections=512

3，开启缓存机制

skip-locking #取消文件系统的外部锁
key_buffer = 512M #索引缓存,根据内存大小而定,若是是独立的db服务器,能够设置高达80%的内存总量
back_log = 200 #链接排队列表总数
max_allowed_packet = 2M 
#打开表缓存总数,能够避免频繁的打开数据表产生的开销
table_cache = 512 
#每一个线程排序所需的缓冲
sort_buffer_size = 4M 
#MyISAM表发生变化时从新排序所需的缓冲
myisam_sort_buffer_size = 64M 
#缓存可重用的线程数
thread_cache = 128 
#查询结果缓存
query_cache_size = 128M 
#设置超时时间,能避免长链接
wait_timeout=60 
#最大并发线程数,cpu数量*2
thread_concurrency = 4 
#记录慢查询,而后对慢查询一一优化
log_output=FILE  #also can be FILE,TABLE or TABLE or NONE
slow-query-log=1 
slow_query_log_file=log-slow-queries.log
long_query_time = 1

4，安装mytop监控mysql

yum install mytop

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

[mysqld]; enable the slow query log, default 10 secondslog-slow-queries; 
log queries taking longer than 5 secondslong_query_time = 5;
log queries that don't use indexes even if they take less than long_query_time; 
MySQL 4.1 and newer onlylog-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.cnf 中能够启用 32MB 的查询缓存。
监视查询缓存
在启用查询缓存以后，重要的是要理解它是否获得了有效的使用。MySQL 有几个能够查看的变量，能够用来了解缓存中的状况。清单 2 给出了缓存的状态。
清单 2. 显示查询缓存的统计信息

mysql> SHOW STATUS LIKE 'qcache%';
+-------------------------+------------+| Variable_name | Value |
+-------------------------+------------+| Qcache_free_blocks | 5216 || Qcache_free_memory |
14640664 || cache_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)

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 资源设置

max_connections = 500
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/my.cnf 中的 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. 显示线程使用统计信息

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，就应该与开发人员讨论一下对这些查询进行调优了!
3 个必不可少的工具
尽管在了解具体设置时，SHOW STATUS 命令会很是有用，可是您还须要一些工具来解释 mysqld 所提供的大量数据。我发现有 3 个工具是必不可少的;在 参考资料 一节中您能够找到相应的连接。

mytop 大部分系统管理员都很是熟悉 top 命令，它为任务所消耗的 CPU 和内存提供了一个不断更新的视图。 mytop 对 top 进行了仿真;它为全部链接上的客户机以及它们正在运行的查询提供了一个视图。mytop 还提供了一个有关关键字缓冲区和查询缓存效率的实时数据和历史数据，以及有关正在运行的查询的统计信息。这是一个颇有用的工具，能够查看系统中(好比 10 秒钟以内)的情况，您能够得到有关服务器健康信息的视图，并显示致使问题的任何链接。
mysqlard 是一个链接到 MySQL 服务器上的守护程序，负责每 5 分钟搜集一次数据，并将它们存储到后台的一个 Round Robin Database 中。有一个 Web 页面会显示这些数据，例如表缓存的使用状况、关键字效率、链接上的客户机以及临时表的使用状况。尽管 mytop 提供了服务器健康信息的快照，可是 mysqlard 则提供了长期的健康信息。而且mysqlard 使用本身搜集到的一些信息针对如何对服务器进行调优给出一些建议。
mysqlreport 搜集 SHOW STATUS 信息的另一个工具是 mysqlreport。其报告要远比 mysqlard 更加复杂，由于须要对服务器的每一个方面都进行分析。这是对服务器进行调优的一个很是好的工具，由于它对状态变量进行适当计算来帮助肯定须要修正哪些问题。
结束语
本文介绍了对 MySQL 进行调优的一些基础知识，调优很大程度上须要理解组件的工做原理，肯定它们是否正常工做，进行一些调整，并从新评测。每一个组件 —— Linux、Apache、PHP 或 MySQL —— 都有各类各样的需求。分别理解各个组件能够帮助减小可能会致使应用程序速度变慢的瓶颈。
mytop使用方法：

# mytop -u root -p 123456 -d mydb_name

显示结果：
第一行显示了主机名称，还有至今 MySQL 的运行时间 (以 days+hour:minutes:seconds 为格式)。
第二行的 Queries 显示了至今执行的 SQL 查询语句总数，另外还有目前每秒处理的查询数和速度。
第三行的 Key Efficiency 就是传说中的缓存命中率了，若是过低了你可能要调整你的 MySQL 设置，或者调整一下表的结构，后面还有目前的进出速度。
最下方的区域就是目前连接到数据库的各个线程，你能够按 k 杀死一个线程，或者按 f 了解特定线程的信息。