【处理中】mysql 只读 slave 数据库，每日大量慢查询。

lxxpsp2007

   
我们公司的一台 slave mysql 服务器，提供只读服务。  MYISAM 引擎
  每天都有 150MB左右的 慢查询日志。
  我单独拿出这些被记录到慢日志的 语句 执行，发现速度很快的。
  慢查询设置超过1秒被记录。
  我很迷惑，明明语句不变态也有索引，手动单独执行也很快。 不知道为什么被记录近了慢查询日志。
  请大家指点迷津，或者给个思路，谢谢大家。
  比如下面经过 mysqlsla 处理后的排名第一慢的

1. Count         : 4.58k  (2.68%)
   
2. Time          : 4617 s total, 1.008739 s avg, 1 s to 4 s max  (6.20%)
   
3.   95% of Time : 4348 s total, 1 s avg, 1 s to 1 s max
   
4. Lock Time (s) : 1 s total, 218 祍 avg, 0 to 1 s max  (3.85%)
   
5.   95% of Lock : 0 total, 0 avg, 0 to 0 max
   
6. Rows sent     : 16 avg, 15 to 16 max  (0.75%)
   
7. Rows examined : 46 avg, 32 to 48 max  (0.09%)
   
8. Database      : xxpp_data
   
9. Users         :
   
10.         xxppx@ 192.168.0.101 : 42.30% (1936) of query, 41.27% (70379) of all users
    
11.         xxppx@ 192.168.0.102 : 33.71% (1543) of query, 32.70% (55761) of all users
    
12.         xxppx@ 192.168.0.103 : 23.99% (1098) of query, 24.35% (41533) of all users
    
13. 
    
14. Query abstract:
    
15. SELECT m.id, m.title, from_unixtime( m.cdate, 'S') AS cdate, from_unixtime( m.udate, 'S') AS udate, m.image, m.spec, m.product_area, m.shop_id, m.gcid, s.rid, m.price, m.stat, s.company, s.level AS shop_level, b.title AS brand, b.id AS brand_id, N AS type, unit FROM xxpp_goods.goods AS m LEFT JOIN xxpp.shop AS s ON m.shop_id = s.id LEFT JOIN xxpp.brand AS b ON m.brand_id = b.id WHERE m.id IN (N16);
    
16. Query sample:
    
17. SELECT
    
18.                 m.id,
    
19.                 m.title,
    
20.                 FROM_UNIXTIME( m.cdate, '%Y-%m-%d %H:%i') AS cdate,
    
21.                 FROM_UNIXTIME( m.udate, '%Y-%m-%d %H:%i') AS udate,
    
22.                 m.image,
    
23.                 m.spec,
    
24.                 m.product_area,
    
25.                 m.shop_id,
    
26.                 m.gcid,
    
27.                 s.rid,
    
28.                 m.price,
    
29.                 m.stat,
    
30.                 s.company,
    
31.                 s.level AS shop_level,
    
32.                 b.title AS brand,
    
33.                 b.id AS brand_id,
    
34.                 1 AS type,
    
35.                 unit
    
36.             FROM xxpp_goods.goods AS m
    
37.                 LEFT JOIN xxpp.shop as s ON m.shop_id = s.id
    
38.                 LEFT JOIN xxpp.brand AS b ON m.brand_id = b.id
    
39.             WHERE m.id IN (2676271,2667626,2769278,2915621,2542843,1635917,1788116,2662136,2505980,1201328,2493089,1995808,2490642,2125146,2042179,2068516);

复制代码

ruochen

贴出来

lxxpsp2007

回复 2# ruochen


    请你帮忙看看。我贴了一个。
   加 explain 后的结果

1. +----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------------+
   
2. | id | select_type | table | type   | possible_keys | key     | key_len | ref                       | rows | Extra       |
   
3. +----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------------+
   
4. |  1 | SIMPLE      | m     | range  | PRIMARY       | PRIMARY | 8       | NULL                      |   16 | Using where |
   
5. |  1 | SIMPLE      | s     | eq_ref | PRIMARY       | PRIMARY | 8       | xxpp_goods.m.shop_id  |    1 |             |
   
6. |  1 | SIMPLE      | b     | eq_ref | PRIMARY       | PRIMARY | 4       | xxpp_goods.m.brand_id |    1 |             |
   
7. +----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------------+
   
8. 3 rows in set (0.00 sec)

复制代码

chinafenghao

@lxxpsp2007
给你几点可能的原因。
1、query cache导致的。
2、磁盘IO不够导致的
3、某个执行次数并不多，但是执行时间很长，相当消耗资源的查询。

spser

明显的是进程堵塞原因嘛.

lxxpsp2007

回复 4# chinafenghao


    谢谢你的思路。我去挨个看。

Shaquile

你的情况是否为：

query单次执行很快，但高并发时，就慢了？

你查一下，并发的配置，如：并发数等

wangjj20

可能某个出现次数不多，但是速度很慢的sql导致的堵塞。