mysql性能的检查和调优步骤

mysql性能的检查和调优方法 我一直是使用mysql这个数据库，它工作比较稳定，效率也很高。在遇到严重性能问题时，一般都有这么几种可能： 1、索引没有建好； 2、sql写法过于复杂； 3、配置错误； 4、机器实在负荷不了； 1、索引没有建好 如果看到mysql消耗的cp

mysql性能的检查和调优方法
我一直是使用mysql这个数据库，它工作比较稳定，效率也很高。在遇到严重性能问题时，一般都有这么几种可能：

1、索引没有建好；
2、sql写法过于复杂；
3、配置错误；
4、机器实在负荷不了；

1、索引没有建好

如果看到mysql消耗的cpu很大，可以用mysql的client工具来检查。

在linux下执行

/usr/local/mysql/bin/mysql -hlocalhost -uroot -p

输入密码，如果没有密码，则不用-p参数就可以进到客户端界面中。

看看当前的运行情况

show full processlist

可以多运行几次

这个命令可以看到当前正在执行的sql语句，它会告知执行的sql、数据库名、执行的状态、来自的客户端ip、所使用的帐号、运行时间等信息

在我的cache后端，这里面大部分时间是看不到显示任何sql语句的，我认为这样才算比较正常。如果看到有很多sql语句，那么这台mysql就一定会有性能问题

如果出现了性能问题，则可以进行分析：

1、是不是有sql语句卡住了？

这是出现比较多的情况，如果数据库是采用myisam，那么有可能有一个写入的线程会把数据表给锁定了，如果这条语句不结束，则其它语句也无法运行。

查看processlist里的time这一项，看看有没有执行时间很长的语句，要留意这些语句。

2、大量相同的sql语句正在执行

如果出现这种情况，则有可能是该sql语句执行的效率低下，同样要留意这些语句。

然后把你所怀疑的语句统统集合一下，用desc（explain）来检查这些语句。

首先看看一个正常的desc输出：

mysql> desc select * from imgs where imgid=1651768337;
+—-+————-+——-+——-+—————+———+———+——-+——+——-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——-+—————+———+———+——-+——+——-+
| 1 | SIMPLE | imgs | const | PRIMARY | PRIMARY | 8 | const | 1 | |
+—-+————-+——-+——-+—————+———+———+——-+——+——-+
1 row in set (0.00 sec)

注意key、rows和Extra这三项，这条语句返回的结果说明了该sql会使用PRIMARY主键索引来查询，结果集数量为1条，Extra没有显 示，证明没有用到排序或其他操作。由此结果可以推断，mysql会从索引中查询imgid=1651768337这条记录，然后再到真实表中取出所有字 段，是很简单的操作。

key是指明当前sql会使用的索引，mysql执行一条简单语句时只能使用到一条索引，注意这个限制；rows是返回的结果集大小，结果集就是使用该索引进行一次搜索的所有匹配结果；Extra一般会显示查询和排序的方式，。

如果没有使用到key，或者rows很大而用到了filesort排序，一般都会影响到效率，例如：

mysql> desc select * from imgs where userid=”7mini” order by clicks desc limit 10;
+—-+————-+——-+——+—————+——+———+——+——-+—————————–+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——+—————+——+———+——+——-+—————————–+
| 1 | SIMPLE | imgs | ALL | NULL | NULL | NULL | NULL | 12506 | Using where; Using filesort |
+—-+————-+——-+——+—————+——+———+——+——-+—————————–+
1 row in set (0.00 sec)

这条sql结果集会有12506条，用到了filesort，所以执行起来会非常消耗效率的。这时mysql执行时会把整个表扫描一遍，一条一条去找到匹 配userid=”7mini”的记录，然后还要对这些记录的clicks进行一次排序，效率可想而知。真实执行时如果发现还比较快的话，那是因为服务器 内存还足够将12506条比较短小的记录全部读入内存，所以还比较快，但是并发多起来或者表大起来的话，效率问题就严重了。

这时我把userid加入索引：

create index userid on imgs (userid);

然后再检查：

mysql> desc select * from imgs where userid=”7mini” order by clicks desc limit 10;
+本文来源gaodai$ma#com搞$代*码*网—-+————-+——-+——+—————+——–+———+——-+——+—————————–+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——+—————+——–+———+——-+——+—————————–+
| 1 | SIMPLE | imgs | ref | userid | userid | 51 | const | 8 | Using where; Using filesort |
+—-+————-+——-+——+—————+——–+———+——-+——+—————————–+
1 row in set (0.00 sec)

喜欢 (0)赏

[搞代码]

分享 (0)