mysql 慢查询分析 第一篇

mysql的性能调优之慢查询

如何分析慢查询,大致分三步,

1 开启慢查询日志 2 抓出慢查询sql语句 3 优化sql(索引有没有加之类)

针对2.开侃:

首先搞清楚各个字段的含义: 很关键的一步,直接影响分析慢查询

select_type: 

simple 单表查询

primary 主查询,即外层查询

union union中的第二个或后面的查询

subquery 子查询中的第一个select

table:输出结果集的表

type:

rang表示表的连接类型,

性能从好到差:

system(表 仅一行)

eq_ref(对于前面的每一行使用主键和唯一索引)

ref(同eq_ref,没有使用主键和唯一)

all(全表扫描)

index(通过查询索引得到数据)

unique_subquery(主键子查询)

possible_keys:表查询时可能使用的索引

key:name 实际使用的索引

key_len: 索引字段的长度

rows:扫描行的数量

extra:执行情况的说明跟描述

结合一个实例看下:(这个sql是学习美团慢查询摘下来的)

select
   distinct cert.emp_id
from
   cm_log cl
inner join
   (
      select
         emp.id as emp_id,
         emp_cert.id as cert_id
      from
         employee emp
      left join
         emp_certificate emp_cert
            on emp.id = emp_cert.emp_id
      where
         emp.is_deleted=0
   ) cert
      on (
         cl.ref_table='Employee'
         and cl.ref_oid= cert.emp_id
      )
      or (
         cl.ref_table='EmpCertificate'
         and cl.ref_oid= cert.cert_id
      )
where
   cl.last_upd_date >='2013-11-07 15:03:00'
   and cl.last_upd_date<='2013-11-08 16:00:00';
  
   +----+-------------+------------+-------+---------------------------------+-----------------------+---------+-------------------+-------+--------------------------------+
| id | select_type | table      | type  | possible_keys                   | key                   | key_len | ref               | rows  | Extra                          |
+----+-------------+------------+-------+---------------------------------+-----------------------+---------+-------------------+-------+--------------------------------+
|  1 | PRIMARY     | cl         | range | cm_log_cls_id,idx_last_upd_date | idx_last_upd_date     | 8       | NULL              |   379 | Using where; Using temporary   |
|  1 | PRIMARY     | <derived2> | ALL   | NULL                            | NULL                  | NULL    | NULL              | 63727 | Using where; Using join buffer |
|  2 | DERIVED     | emp        | ALL   | NULL                            | NULL                  | NULL    | NULL              | 13317 | Using where                    |
|  2 | DERIVED     | emp_cert   | ref   | emp_certificate_empid           | emp_certificate_empid | 4       | meituanorg.emp.id |     1 | Using index                    |
+----+-------------+------------+-------+---------------------------------+-----------------------+---------+-------------------+-------+--------------------------------+

我们可以直接分析结果了 :

首先 id分为1,2

1 代表外层查询,即cl表跟derived2(该表是个中间表,由2内层查询构建的)表作的关联查询

2表示内层查询,即emp表与emp_cert表关联所得

来看rows ,第一行 379 说明cl表只影响379行而且用到了索引关键字 idx_last_upd_date,

第二行, derived2表63727行,影响了6w多行,最终结果确实300来行,说明大部分数据没有作用,白扫了,这也就是慢查询的问题了,看看如何降低这个扫描了

下一篇再续吧,开会了