MySQL性能检测优化工具

还在用show processlist查看进程然后监控Mysql的运行情况吗?你out了!

由M. Montgomery编写的一套脚本可以帮你迅速的判断Mysql服务的运行情况,并对你的Mysql优化与其他处理做出相应有利的建议。

首先,下载tuning-primer(右键另存后传入到服务器即可),或者运行以下指令

wget http://qyappchentao.sinaapp.com/wp-content/uploads/2013/08/tuning-primer.zip

接下来解压到当前文件夹,复制一份到my.cnf同目录下,我这里是/etc/

然后赋予这个脚本执行权限,最好将文件属性设置为MySQL用户:
chmod a+x tuning-primer.sh(不做此修改也可,需要运行时加入 sh filename)

chown root:root tuning-primer.sh

这样就大功告成了!

如果你的MySQL在管理员权限下需要输入密码,脚本会提示你手动输入或者遵循my.cnf中的配置。

接下来运行脚本:

./tuning-primer.sh

这个脚本会根据你MySQL服务的实际情况做出判断并给出你相应的调整优化建议:

– MYSQL PERFORMANCE TUNING PRIMER –

  • By: Matthew Montgomery -

MySQL Version 5.0.89-log x86_64(MySQL当前版本)

Uptime = 21 days 23 hrs 8 min 3 sec
Avg. qps = 0
Total Questions = 19080
Threads Connected = 11

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.0/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 enabled.
Current long_query_time = 1 sec.
You have 529 out of 19101 that take longer than 1 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG(二进制升级日志,没有启用)
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html

WORKER THREADS(工作线程)
Current thread_cache_size = 32
Current threads_cached = 1
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine(线程缓存大小还是合适的)

MAX CONNECTIONS(最大连接数)
Current max_connections = 10000
Current threads_connected = 11
Historic max_used_connections = 12
The number of used connections is 0% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See “MEMORY USAGE” section to make sure you are not over-allocating

INNODB STATUS(Innodb引擎状态)
Current InnoDB index space = 0 bytes
Current InnoDB data space = 0 bytes
Current InnoDB buffer pool free = 96 %
Current innodb_buffer_pool_size = 8 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE(内存消耗情况)
Max Memory Ever Allocated : 1.32 G
Configured Max Per-thread Buffers : 238.03 G
Configured Max Global Buffers : 1.04 G
Configured Max Memory Limit : 239.07 G
Physical Memory : 11.63 G

Max memory limit exceeds 90% of physical memory

KEY BUFFER(Key缓存情况)
Current MyISAM index space = 28 M
Current key_buffer_size = 1.00 G
Key cache miss rate is 1 : 2470
Key buffer free ratio = 81 %
Your key_buffer_size seems to be fine

QUERY CACHE(查询缓存)
Query cache is enabled
Current query_cache_size = 32 M
Current query_cache_used = 163 K
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = .49 %
Current query_cache_min_res_unit = 4 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won’t cache query results that are larger than query_cache_limit in size

SORT OPERATIONS(排序操作)
Current sort_buffer_size = 4 M
Current read_rnd_buffer_size = 16 M
Sort buffer seems to be fine

JOINS(连接)
Current join_buffer_size = 132.00 K
You have had 0 queries where a join could not use an index properly
Your joins seem to be using indexes properly

OPEN FILES LIMIT(打开文件限制,类似于文件描述符)
Current open_files_limit = 51200 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_cache value = 1024 tables
You have a total of 38 tables
You have 41 open tables.
The table_cache value seems to be fine

TEMP TABLES(临时表状态)
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 725 temp tables, 2% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS(表扫描情况)
Current read_buffer_size = 4 M
Current table scan ratio = 11165776 : 1
read_buffer_size seems to be fine

TABLE LOCKING(表加锁情况)
Current Lock Wait ratio = 0 : 19356
Your table locking seems to be fine