根据status信息对MySQL服务器进行优化

网上有很多的文章教怎么配置MySQL服务器，但考虑到服务器硬件配置的不同，具体应用的差别，那些文章的做法只能作为初步设置参考，我们需要根据自己的情况进行配置优化，好的做法是MySQL服务器稳定运行了一段时间后运行，根据服务器的”状态”进行优化。

mysql> show global status;

可以列出MySQL服务器运行各种状态值，另外，查询MySQL服务器配置信息语句：

mysql> show variables;

一、慢查询

mysql> show variables like "%slow%";
+------------------+-------+
| Variable_name   | Value |
+------------------+-------+
| log_slow_queries | ON   |
| slow_launch_time | 2    |
+------------------+-------+

mysql> show global status like "%slow%";
+---------------------+-------+
| Variable_name      | Value |
+---------------------+-------+
| Slow_launch_threads | 0    |
| Slow_queries       | 4148 |
+---------------------+-------+

配置中打开了记录慢查询，执行时间超过2秒的即为慢查询，系统显示有4148个慢查询，你可以分析慢查询日志，找出有问题的SQL语句，慢查询时间不宜设置过长，否则意义不大，最好在5秒以内，如果你需要微秒级别的慢查询，可以考虑给MySQL打补丁，记得找对应的版本。打开慢查询日志可能会对系统性能有一点点影响，如果你的MySQL是主－从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响又小。二、连接数经常会遇见”MySQL: ERROR 1040: Too many connections”的情况，一种是访问量确实很高，MySQL服务器抗不住，这个时候就要考虑增加从服务器分散读压力，另外一种情况是MySQL配置文件中max_connections值过小：

mysql> show variables like "max_connections";
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 256 |
+-----------------+-------+

这台MySQL服务器最大连接数是256，然后查询一下服务器响应的最大连接数：

mysql> show global status like "Max_used_connections";

MySQL服务器过去的最大连接数是245，没有达到服务器连接数上限256，应该没有出现1040错误，比较理想的设置是：

Max_used_connections / max_connections * 100% ≈ 85%

最大连接数占上限连接数的85％左右，如果发现比例在10%以下，MySQL服务器连接数上限设置的过高了。三、Key_buffer_sizekey_buffer_size是对MyISAM表性能影响最大的一个参数，下面一台以MyISAM为主要存储引擎服务器的配置：

mysql> show variables like "key_buffer_size";+-----------------+------------+
| Variable_name | Value |
+-----------------+------------+
| key_buffer_size | 536870912 |
+-----------------+------------+

分配了512MB内存给key_buffer_size，我们再看一下key_buffer_size的使用情况：

mysql> show global status like "key_read%";
+------------------------+-------------+
| Variable_name         | Value      |
+------------------------+-------------+
| Key_read_requests     | 27813678764 |
| Key_reads             | 6798830    |
+------------------------+-------------+

一共有27813678764个索引读取请求，有6798830个请求在内存中没有找到直接从硬盘读取索引，计算索引未命中缓存的概率：

key_cache_miss_rate ＝ Key_reads / Key_read_requests * 100%

比如上面的数据，key_cache_miss_rate为0.0244%，4000个索引读取请求才有一个直接读硬盘，已经很BT 了，key_cache_miss_rate在0.1%以下都很好（每1000个请求有一个直接读硬盘），如果key_cache_miss_rate在 0.01%以下的话，key_buffer_size分配的过多，可以适当减少。MySQL服务器还提供了key_blocks_*参数：

mysql> show global status like "key_blocks_u%";
+------------------------+-------------+
| Variable_name         | Value      |
+------------------------+-------------+
| Key_blocks_unused     | 0          |
| Key_blocks_used       | 413543     |
+------------------------+-------------+

Key_blocks_unused表示未使用的缓存簇（blocks）数，Key_blocks_used表示曾经用到的最大的blocks数，比如这台服务器，所有的缓存都用到了，要么增加key_buffer_size，要么就是过渡索引了，把缓存占满了。比较理想的设置：Key_blocks_used / （Key_blocks_unused + Key_blocks_used） * 100% ≈ 80%

Oralce TNS:监听程序当前无法识别连接MySQL的myisam解决并发读写解决方法相关资讯 MySQL教程

30分钟带你快速入门MySQL教程（02月03日）
MySQL教程：关于I/O内存方面的一些（01月24日）
CentOS上开启MySQL远程访问权限（01/29/2013 10:58:40）

MySQL教程：关于checkpoint机制（01月24日）
MySQL::Sandbox （04/14/2013 08:03:38）
生产环境MySQL 5.5.x单机多实例配（11/02/2012 21:02:36）

本文评论查看全部评论（0）