mysql性能优化工具--tuner-primer使用介绍

各位用户为了找寻关于mysql性能优化工具--tuner-primer使用介绍的资料费劲了很多周折。这里教程网为您整理了关于mysql性能优化工具--tuner-primer使用介绍的相关资料，仅供查阅，以下为您介绍关于mysql性能优化工具--tuner-primer使用介绍的详细内容

下载并改变执行权限： wget http://www.day32.com/MySQL/tuning-primer.sh chmod +x tuning-primer.sh ./tuning-primer.sh 结果报告： 会用几种颜色标记： 蓝色：总指标 绿色：表示此参数还可以 红色：表示此参数有严重问题 深红色：表示有问题参数 黄色：一些信息提示 而且还有警告： Note! This script will still suggest raising the join_buffer_size when ANY joins not using indexes are found. 下面是一个报告的结果 xx@xxxxxx:~$ . ./tuning-primer.sh mysqld is alive -- MYSQL PERFORMANCE TUNING PRIMER -- - By: Matthew Montgomery - MySQL Version 5.1.32-enterprise-gpl-log x86_64 Uptime = 4 days 0 hrs 48 min 3 sec Avg. qps = 255 Total Questions = 88956118 Threads Connected = 4 Server has been running for over 48hrs. It should be safe to follow these recommendations To find out more information on how each of these runtime variables effects performance visit: http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html Visit http://www.mysql.com/products/enterprise/advisors.html for info about MySQL's Enterprise Monitoring and Advisory Service SLOW QUERIES The slow query log is NOT enabled. Current long_query_time = 10.000000 sec. You have 9589 out of 88956228 that take longer than 10.000000 sec. to complete Your long_query_time seems to be fine BINARY UPDATE LOG The binary update log is enabled The expire_logs_days is not set. The mysqld will retain the entire binary log until RESET MASTER or PURGE MASTER LOGS commands are run manually Setting expire_logs_days will allow you to remove old binary logs automatically See http://dev.mysql.com/doc/refman/5.1/en/purge-master-logs.html WORKER THREADS Current thread_cache_size = 32 Current threads_cached = 29 Current threads_per_sec = 0 Historic threads_per_sec = 0 Your thread_cache_size is fine MAX CONNECTIONS Current max_connections = 151 Current threads_connected = 4 Historic max_used_connections = 84 The number of used connections is 55% of the configured maximum. Your max_connections variable seems to be fine. MEMORY USAGE Max Memory Ever Allocated : 11.87 G Configured Max Per-thread Buffers : 10.38 G Configured Max Global Buffers : 6.10 G Configured Max Memory Limit : 16.48 G Physical Memory : 8.00 G Max memory limit exceeds 90% of physical memory （内存设置严重有问题！--By Me） KEY BUFFER 1714734 * 1024 / 2147483648 * 100 Current MyISAM index space = 8 K Current key_buffer_size = 2.00 G Key cache miss rate is 1 : 585673 Key buffer free ratio = 0 % Your key_buffer_size seems to be too high. Perhaps you can use these resources elsewhere （错误参数设置：query_cache_size > query_cache_limit --By Me） SORT OPERATIONS Current sort_buffer_size = 4 M Current read_rnd_buffer_size = 64 M Sort buffer seems to be fine JOINS Current join_buffer_size = 132.00 K You have had 1 queries where a join could not use an index properly You should enable "log-queries-not-using-indexes" Then look for non indexed joins in the slow query log. If you are unable to optimize your queries you may want to increase your join_buffer_size to accommodate larger joins in one pass. Note! This script will still suggest raising the join_buffer_size when ANY joins not using indexes are found. （ join_buffer_size设置过小，另外存在一个查询使用了join但是没有走索引 --By Me） OPEN FILES LIMIT Current open_files_limit = 1185 files The open_files_limit should typically be set to at least 2x-3x that of table_cache if you have heavy MyISAM usage. Your open_files_limit value seems to be fine TABLE CACHE Current table_open_cache = 512 tables Current table_definition_cache = 256 tables You have a total of 0 tables You have 125 open tables.

TABLE SCANSCurrent read_buffer_size = 2 M Current table scan ratio = 4650 : 1 You have a high ratio of sequential access requests to SELECTs You may benefit from raising read_buffer_size and/or improving your use of indexes. TABLE LOCKING Current Lock Wait ratio = 1 : 5833374 Your table locking seems to be fine