MySQL性能分析及explain的使用(转)

一、使用explain语句去查看分析结果,如
explain select * from test1 where id=1;
会出现:
id  selecttype  table  type possible_keys  key key_len  ref rows  extra
其中
  • type=const表示经过索引一次就找到了
  • key=primary的话,表示使用了主键 
  • type=all表示为全表扫描
  • key=null表示没用到索引
  • type=ref由于这时认为是多个匹配行,在联合查询中,通常为ref
二、MySQL中的组合索引

假设表有id,key1,key2,key3,把三者造成一个组合索引,则html

如:mysql

where key1=.... where key1=1 and key2=2 where key1=3 and key3=3 and key2=2sql

根据最左原则,这些都是可使用索引的

性能

from test where key1=1 order by key3
用explain分析的话,只用到了normal_key索引,但只对where子句起做用,然后面的order by须要排序

三、使用慢查询分析:spa

在my.ini中:日志

long_query_time=1
log-slow-queries=d:\mysql5\logs\mysqlslow.log

把超过1秒的记录在慢查询日志中code

能够用mysqlsla来分析之。也能够在mysqlreport中,有如DMS分别分析了select,update,insert,delete,replace等所占的百份比orm

四、MyISAM和InnoDB的锁定htm

MyISAM中,注意是表锁来的,好比在多个update操做后,再select时,会发现select操做被锁定了,必须等全部update操做完毕后,再能select blog

InnoDB的话则不一样了,用的是行锁,不存在上面问题。

五、MySQL的事务配置项

innodb_flush_log_at_trx_commit=1
表示事务提交时当即把事务日志写入磁盘,同时数据和索引也更新
innodb_flush_log_at_trx_commit=0
事务提交时,不当即把事务日志写入磁盘,每隔1秒写一次
innodb_flush_log_at_trx_commit=2
事务提交时,当即写入磁盘文件(这里只是写入到内核缓冲区,但不当即刷新到磁盘,而是每隔1秒刷新到盘,同时更新数据和索引)

六、explain用法

explain tbl_name
或:
explain [extended] select select_options
前者能够得出一个表的字段结构等等,后者主要是给出相关的一些索引信息,而今天要讲述的重点是后者。
举例:
explain select * from event;
+-+————-+——-+——+—————+——+———+——+——+——-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+-+————-+——-+——+—————+——+———+——+——+——-+
| 1 | SIMPLE | event | ALL | NULL | NULL | NULL | NULL | 13 | |
+-+————-+——-+——+—————+——+———+——+——+——-+
1 row in set (0.00 sec)
各个属性的含义:
  • id
    • select查询的序列号
    • select_type
    • select查询的类型,主要是区别普通查询和联合查询、子查询之类的复杂查询。
  • table
    • 输出的行所引用的表。
  • type
    • 联合查询所使用的类型。
    • type显示的是访问类型,是较为重要的一个指标,结果值从好到坏依次是:
    • system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
    • 通常来讲,得保证查询至少达到range级别,最好能达到ref。
  • possible_keys
    • 指出MySQL能使用哪一个索引在该表中找到行。若是是空的,没有相关的索引。这时要提升性能,可经过检验where子句,看是否引用某些字段,或者检查字段不是适合索引。
  • key
    • 显示MySQL实际决定使用的键。若是没有索引被选择,键是null。
  • key_len
    • 显示MySQL决定使用的键长度。若是键是null,长度就是null。文档提示特别注意这个值能够得出一个多重主键里MySQL实际使用了哪一部分。
  • ref
    • 显示哪一个字段或常数与key一块儿被使用。
  • rows
    • 这个数表示MySQL要遍历多少数据才能找到,在InnoDB上是不许确的。
  • Extra
    • 若是是only index,这意味着信息只用索引树中的信息检索出的,这比扫描整个表要快。
    • 若是是where used,就是使用上了where限制。
    • 若是是impossible where 表示用不着where,通常就是没查出来啥。
    • 若是此信息显示using filesort或者using temporary的话会很吃力,where和order by的索引常常没法兼顾,若是按照where来肯定索引,那么在order by时,就必然会引发using filesort,这就要看是先过滤再排序划算,仍是先排序再过滤划算。
  • 常见的一些名词解释
    • using filesort
      • MySQL须要额外的一次传递,以找出如何按排序顺序检索行。
    • using index
      • 从只使用索引树中的信息而不须要进一步搜索读取实际的行来检索表中的列信息。
    • using temporary
      • 为了解决查询,MySQL须要建立一个临时表来容纳结果。
    • ref
      • 对于每一个来自于前面的表的行组合,全部有匹配索引值的行将从这张表中读取
    • all
      • 彻底没有索引的状况,性能很是地差劲。
    • index
      • 与all相同,除了只有索引树被扫描。这一般比all快,由于索引文件一般比数据文件小。
    • simple
      • 简单select(不使用union或子查询) 

 

参考:

http://blog.sina.com.cn/s/blog_4586764e0100o9s1.html(以上内容转自此篇文章)

相关文章
相关标签/搜索