清单 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 个工具是必不可少的;在 参考资料 一节中您可以找到相应的链接。
　　大部分系统管理员都非常熟悉 top 命令，它为任务所消耗的 CPU 和内存提供了一个不断更新的视图。 mytop 对 top 进行了仿真;它为所有连接上的客户机以及它们正在运行的查询提供了一个视图。mytop 还提供了一个有关关键字缓冲区和查询缓存效率的实时数据和历史数据，以及有关正在运行的查询的统计信息。这是一个很有用的工具，可以查看系统中(比如 10 秒钟之内)的状况，您可以获得有关服务器健康信息的视图，并显示导致问题的任何连接。
　　mysqlard 是一个连接到 MySQL 服务器上的守护程序，负责每 5 分钟搜集一次数据，并将它们存储到后台的一个 Round Robin Database 中。有一个 Web 页面会显示这些数据，例如表缓存的使用情况、关键字效率、连接上的客户机以及临时表的使用情况。尽管 mytop 提供了服务器健康信息的快照，但是 mysqlard 则提供了长期的健康信息。作为奖励，mysqlard 使用自己搜集到的一些信息针对如何对服务器进行调优给出一些建议。
　　搜集 SHOW STATUS 信息的另外一个工具是 mysqlreport。其报告要远比 mysqlard 更加复杂，因为需要对服务器的每个方面都进行分析。这是对服务器进行调优的一个非常好的工具，因为它对状态变量进行适当计算来帮助确定需要修正哪些问题。
　　结束语
　　本文介绍了对 MySQL 进行调优的一些基础知识，并对这个针对 LAMP 组件进行调优的 3 部分系列文章进行了总结。调优很大程度上需要理解组件的工作原理，确定它们是否正常工作，进行一些调整，并重新评测。每个组件 —— 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 了解特定线程的信息。
　　以上是myql优化，启动mysql缓存机制，实现命中率的全文介绍，希望对您学习和使用mysql有所帮助.