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