急求，mysql 经常导致CPU使用率100%

yueliangdao0608

开启一下慢查询，然后调整一下吧。

枫影谁用了

原帖由 willko 于 2008-7-28 13:03 发表
明显是因为SQL语句的问题了。。。。。。。。
一个SQL有问题，，并发多几条，，整个MYSQL就锁住了。。。

SQL的优化空间不大了。

倒是我一开始没留意IO的问题。

这个的IO确实有问题。

zhangjoto

让我猜测一下楼主的主机,大概是一台普通PC做服务器,只有一块本地硬盘,所有的东西(包括操作系统,mysql,应用等)都在这块硬盘上?
如果是这样的话,楼主的IO问题基本上没有多大的调整余地了,这方面唯一还可以看看的就是hdparm是否起了作用.
剩下的就只有从应用和数据库两方面着手:
1.sql优化
2.表分区
3.减小关键的规模
3.优化mysql参数,尽可能让查询动作利用内存就可以完成
总而言之核心思想就是尽可能的减小IO

sunnyfun

SELECT attach.aid, attach.attachment, t.tid, t.fid, t.subject FROM cdb_attachments attach LEFT JOIN cdb_threads t ON t.tid=attach.tid WHERE attach.readperm='0' AND displayorder>='0' AND filetype like 'image/%g%'  GROUP BY attach.tid ORDER BY attach.dateline DESC LIMIT 0, 50;

先看看这个

like 'image/%g%'

去掉后执行的时间，有提升的话就改改。

SELECT t.*, f.name FROM cdb_threads t, cdb_forums f WHERE f.fid=t.fid AND f.fid not in (41) AND t.displayorder not in (-1,-2) AND t.closed NOT LIKE 'moved|%' AND t.replies !=0 ORDER BY t.lastpost DESC LIMIT 0, 10;

不清楚为什么里面要有这么多not，如果不是很关键的信息的话，缓存一下数据，定时更新一下可能会好点。

ruochen

Mem:    969608k total,   448192k used,   521416k free,      976k buffers
Swap: 11582856k total,   140068k used, 11442788k free,    36688k cached

内存的使用很奇怪

sunboyu

垃圾sql语句的可能性最高

eugene_jin

我没看大家的回帖，，只看lZ贴出的参数信息：
| Handler_read_rnd_next             | 1582   

LZ看下这个参数信息就应该知道有多少读在等待。。。。

说明读写速度可能有点问题。。。。你比较下key_read_request/Key_read
Key_write__request/Key_write 比如如何。。。。。然后再去检测下慢查询。。。。

我相信此那个这个两个方面综合区考虑应该可以解决lZ的问题

yueliangdao0608

原帖由 eugene_jin 于 2008-7-28 16:36 发表
我没看大家的回帖，，只看lZ贴出的参数信息：
| Handler_read_rnd_next             | 1582   

LZ看下这个参数信息就应该知道有多少读在等待。。。。

说明读写速度可能有点问题。。。。你比较下key_read ...

老金来了

枫影谁用了

原帖由 eugene_jin 于 2008-7-28 16:36 发表
我没看大家的回帖，，只看lZ贴出的参数信息：
| Handler_read_rnd_next             | 1582   

LZ看下这个参数信息就应该知道有多少读在等待。。。。

说明读写速度可能有点问题。。。。你比较下key_read ...

小白菜插一下队。

(root:localhost:)gdas> show status like '%Handler_read_rnd_next%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Handler_read_rnd_next | 1448  |
+-----------------------+-------+
1 row in set (0.03 sec)


上面是我从我这边某一台DB上看到的。


现在这个DB有1百多个连接，负载是0.几。

这说明不了问题吧，哥们。

枫影谁用了

天于读缓冲的解释：

读缓冲区(read_buffer_size)

理想情况下，索引提供了足够多的信息，可以只读入所需要的行。

但是有时候查询，需要读取表中大量数据。

要理解这种行为，需要知道运行了多少个 SELECT 语句Com_select ，以及需要读取表中的下一行数据的次数Handler_read_rnd_next。



mysql> SHOW STATUS LIKE "handler_read_rnd_next";

+-----------------------+-----------+

| Variable_name | Value |

+-----------------------+-----------+

| Handler_read_rnd_next | 788605837 |

+-----------------------+-----------+

1 row in set (0.00 sec)


mysql> SHOW STATUS LIKE "com_select";

+---------------+-----------+

| Variable_name | Value |

+---------------+-----------+

| Com_select | 185910100 |

+---------------+-----------+

1 row in set (0.00 sec)


mysql>



Handler_read_rnd_next/Com_select =1/5 。如果该值超过4000，就应该查看read_buffer_size，虚拟系统为131072。

read_buffer_size

每个线程连续扫描时为扫描的每个表分配的缓冲区的大小(字节)。如果进行多次连续扫描，可能需要增加该值，默认值为131072。