mysql慢查询日志

前提环境:

  • 创库:slow_testcreate database slow_test;
  • 选定库:use slow_test;
  • 创表comic:create table comic(comic_id int primary key auto_increment,name char(20),pen_name char(20),cover char(40));
    image.png
delimiter  //

create procedure insert_many()
begin
declare i int;
set i =0;
while i<10 do
insert into comic (name,pen_name,cover) select name,pen_name,cover from comic;
set i=i+1;
end while;
end;
//

delimiter ;
image.png
image.png
image.png
image.png

一、生成实验数据

原理:sql 蠕虫复制(这种生成数据方式同样适用于数据表中有主键的情况)。

insert into comic (name,pen_name,cover) select name,pen_name,cover from comic

二、慢查询日志设置

当语句执行时间较长时,通过日志的方式进行记录,这种方式就是慢查询的日志。

  • 1、临时开启慢查询日志(如果需要长时间开启,则需要更改mysql配置文件,第6点有介绍)
set global slow_query_log = on; 

注:如果想关闭慢查询日志,只需要执行 set global slow_query_log = off; 即可


image.png
  • 2、临时设置慢查询时间临界点 查询时间高于这个临界点的都会被记录到慢查询日志中(如果需要长时间开启,则需要更改mysql配置文件,第6点有介绍)。
set long_query_time = 1;
image.png

现在起,所有执行时间超过1秒的sql都将被记录到慢查询文件中
(我这里就是 /var/lib/mysql/oyzx-slow.log)。
set long_query_time = 1;
show variables like 'slow_query%'; #查看慢日志文件所在目录

image.png

  • 3、设置慢查询存储的方式
set global log_output='FILE';

image.png

说明:可以看到,我这里设置为了file类型,就是说我的慢查询日志是通过file体现的,默认是none,我们可以设置为table或者file,如果是table则慢查询信息会保存到mysql库下的slow_log表中
set global log_output='TABLE';

  • 4、查询慢查询日志的开启状态和慢查询日志储存的位置
show variables like '%quer%';
image.png

image.png

参数说明:
slow_query_log : 是否已经开启慢查询
slow_query_log_file : 慢查询日志文件路径
long_query_time : 超过多少秒的查询就写入日志
log_queries_not_using_indexes 如果值设置为ON,则会记录所有没有利用索引的查询(性能优化时开启此项,平时不要开启)

  • 5、使用慢查询日志示例
cat -n /var/lib/mysql/oyzx-slow.log
image.png

从慢查询日志中,我们可以看到每一条查询时间高于1s钟的sql语句,并可以看到执行的时间是多少。

比如上面,就表示 sql语句 select * from comic; 执行时间为3.30秒,超出了我们设置的慢查询时间临界点1s,所以被记录下来了。

image.png

image.png
  • 6、永久设置慢查询日志开启,以及设置慢查询日志时间临界点
    linux中,mysql配置文件一般默认在/etc/my.cnf
    更改对应参数即可。
    image.png

    systemctl restart mysqld 重启mysql服务
    image.png
image.png
image.png

三、对慢查询日志进行分析

我们通过查看慢查询日志可以发现,很乱,数据量大的时候,可能一天会产生几个G的日志,根本没有办法去清晰明了的分析。所以,这里,我们采用工具进行分析。

  • 1、使用mysqldumpslow进行分析【第一种方式】
mysqldumpslow -t 10  /var/lib/mysql/oyzx-slow.log   #显示出慢查询日志中最慢的10条sql
image.png

注:mysqldumpslow工具还有其他参数,以提供其他功能,这里,只以最基本的-t做了介绍。

  • 2、使用pt-query-digest工具进行分析

mysqldumpslow是mysql安装后就自带的工具,用于分析慢查询日志,但是pt-query-digest却不是mysql自带的,如果想使用pt-query-digest进行慢查询日志的分析,则需要自己安装pt-query-digest。pt-query-digest工具相较于mysqldumpslow功能多一点。

(1)安装及部署

yum install perl-DBI

yum install perl-DBD-MySQL

yum install perl-Time-HiRes

yum install perl-IO-Socket-SSL

yum -y install perl-Digest-MD5

wget percona.com/get/pt-query-digest

chmod u+x pt-query-digest

mv pt-query-digest /usr/bin/

(2)查看具体参数作用

pt-query-digest --help
image.png

(3)使用

pt-query-digest /var/lib/mysql/oyzx-slow.log

查询出来的结果分为三部分

  • 第一部分:
    显示出了日志的时间范围,以及总的sql数量和不同的sql数量。

    image.png

  • 第二部分:
    显示出统计信息。

    image.png

第三部分:
每一个sql具体的分析

image.png

image.png

pct是percent的简写,表示占的百分比
cout是占总sql个数的百分比,
exec time 是占总执行时间的百分比,
lock time表示占总的锁表时间的百分比。

  • (4)如何通过pt-query-digest 慢查询日志发现有问题的sql

1)查询次数多且每次查询占用时间长的sql

通常为pt-query-digest分析的前几个查询

2)IO消耗大的sql

注意pt-query-digest分析中的Rows examine项

3)为命中索引的sql

注意pt-query-digest分析中Rows examine(扫描行数) 和 Rows sent (发送行数)的对比 ,如果扫描行数远远大于发送行数,则说明索引命中率并不高。

四、对sql进行优化

  • 1、使用explain查询sql的执行计划
explain select comic_id,name,pen_name,cover,last_verify_time from comic;

参数分析:

table:表示属于哪张数据表

type:最重要的参数,表示连接使用了何种类型。从最好到最差的连接类型为const,eq_reg,ref,range,index和ALL。

possible_keys:显示可能应用在这张表中的索引。如果为null,则表示没有可能的索引。

key:实际使用的索引。如果为null,则表示没有使用索引。

key_len:使用的索引的长度,在不损失精确性的情况下,长度越短越好。

ref:表示索引的哪一列被使用了,如果可能的话,是一个常数。

rows:Mysql认为必须检查的用来返回请求数据的行数。

  • 2、count() 和 Max() 的优化方法

(1)优化前,是没有为last_update_time字段建立索引的情况,查询最大的时间戳
(2)优化后,是为last_update_time字段建立索引的情况,查询最大的时间戳

create index update_time on comic(last_update_time);

对比,可以看到,在没有为字段建立索引的情况下,查询时间是11秒多,建立索引之后,查询时间变成0秒了。

所以总结就是,如果经常用于count和max操作的字段,可以为其添加索引。

还有,值得注意的地方是:count() 计算时,count(*)会将这一列中的null值但也算进去,而count(comic_id)则不会将null算进去。

  • 3、子查询的优化

通常情况下,需要把子查询优化为join查询,但在优化时要注意关联键是否有一对多的关系,如果有,是可能会出现重复数据的。所以如果存在一对多关系,则应该使用distinct进行限制。
例如:

select t.id from t where t.id in (select k.kid from k);

优化成:

select distinct t.id from t join k on t.id = k.kid;
  • 4、group by 的优化

待补

5、limit的优化

五、对索引进行优化

1、选择合适的列建立索引

2、索引优化sql的方法

3、索引维护的方法

六、数据库结构优化

1、选择合适的数据类型

2、数据库表的范式化优化

3、数据库表的反范式优化

4、数据库表的垂直拆分

5、数据库表的水平拆分

七、系统配置优化
1、数据库系统配置优化

2、Mysql配置文件优化

3、第三方配置工具使用

八、服务器硬件优化

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,236评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,867评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,715评论 0 340
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,899评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,895评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,733评论 1 283
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,085评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,722评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,025评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,696评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,816评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,447评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,057评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,009评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,254评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,204评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,561评论 2 343

推荐阅读更多精彩内容