前一段时间接触MySql 服务器，关于查询忧化方面整理，优化主要唯绕几个工具函数 : show profiling  , explain ,  索引 , limit

如果上司抱怨服务器查询太慢，这时候，你可能会说，可能是网络不好，服务器性能太差。给上司一个合理的说法，私底下，是什么原因，心中要有数。从客户端发起http 请求，到服务端后台业务处理，具体到数据库相关。大多数性能问题出现在数据库上。通常会有这样情况，服务器上线之时，性能还不错，半年之后，网站慢的像蜗牛。在这段时间，在大的架构不变情况，变化部份是数据库文件暴增。因此很可能是数据库拖后腿了。

解决办法有许多种:

1.业务重构，简化现有业务。

2.增加数据缓存组件

3.优化现有数据库或表结构

假设现在已经拿到一段sql 语句，如何对这段sql 做常归性能分析呢？ MySql 提供一些常用工具。首先 将 sql 语句前加 explain ,  mysql 会打印出查询计划:例如:

explain select * from test limit 1

这里有许多列，具体含义可另行搜索 mysql explain 。 重点部份: type possible_key , key , key_len , ref , rows , extra 。

type 属性:  ALL , INDEX , RANGE , REF , EQ_REF , CONST , 从左往右，表现从差到优。

ALL 表明: 当前查询执行全表扫描， 如果在数据量较大表中执行筛选，  显示全表扫描，表明需要添加索引了。

possible_keys 属性: 例举当前sql 可用索引

key:当前查询实际使用索引 (留意关键字 force index(...)  , ignore index(...))

key_len : 当前使用索引颗粒大小

ref : where 子条件哪些列被索引使用

rows:执行查询过程中，扫描了多少行

extra : 额外做了哪些动作,如 Using temporary , Using index , Using  filesort.

例如: explain select SQL_NO_CACHE * from test where year = 2015 and month = 2  ;

以上示例表明:使用了索引 type: ref  , 其中 possible_keys 枚举了能够使用的索引，key 注明实际使用的索引 , key_len 表明索引长度 10 byte, 该值并不是固定的，本例中使用了复合索引，随着复合索引命中的例数增多，key_len 会变大。 ref : const , const , 表明命中复合索引前两列, 如果是: ref:const , const , const ; key_len 的值是15。

rows: 扫描表的行数 ,  值愈小愈好。 limit 关键字无法影响 rows 大小。

例如: explain select SQL_NO_CACHE  * from test where year = 2015 and month = 2 and date = 20 limit 10

请注意，在末尾加了 limit 10 , 但是 MYSQL 仍然扫描了 136176 行 。

开启 MYSQL 执行耗时统计 :

set profiling = 1 ;

显示最近查询sql  耗时

show profiles ;

显示指定查询详细耗时show profile for query [id]