前一段时间接触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]
posted on
