菜单

讨论SQL慢查询的缓解思路。mysql开启慢查询(EXPLAIN SQL语句以介绍)

2018年9月20日 - betway官网手机版

图片 1

今日,数据库的操作更加成为任何应用之性瓶颈了,这点对Web应用越来越明确。关于数据库的特性,这并无一味是DBA才需要担心的从业,而这又是我们程序员需要去关注之作业。当我们错过规划数据库表结构,对操作数据库时(尤其是查表时之SQL语句),我们还用注意数据操作的习性。

近年,在运维部及DBA同事的扶助以及豪门之共同努力下,对项目中之慢SQL进行了优化及更正,效果或不行显的,在这被大家点一个大妈的许。为了为咱们当SQL的拍卖达成更加客观,形成可实施、可借鉴、可参考优化的方案,我当这边梳理一下慢SQL的缓解思路,供大家参考。

1、开启慢查询

慢SQL的体系表现

1> 查看慢查询是否打开

第一,我们什么鉴别系统中碰到了SQL慢查询问题?个人觉得慢SQL有如下三独性状:

show variables like "%quer%";
slow_query_log = ON #已开启

1,数据库CPU负载高。诚如是查询语句被发生不少划算逻辑,导致数据库cpu负载。

2> 开启方法:my.cnf目录配置

2,IO负载高以致服务器卡住。其一一般与全表查询没索引发生提到。

slow_query_log=on #是否开启
slow_query_log_file=/opt/MySQL_Data/TEST1-slow.log #慢查询文件位置
long_query_time=2 #查询超过多少秒才记录

3,查询语句正常,索引正常不过还是慢。要是外部上索引正常,但是查询慢,需要省是不是索引没有奏效。

2、EXPLAIN慢查询日志里出现的SELECT查询

打开SQL慢查询的日记

id select_type table partitions type possible_keys key key_len ref rows filtered Extra
1 SIMPLE user NULL ref user user 768 const 1 100.00 NULL

倘你的系出现了上述情况,并且你莫是为此底阿里云底RDS这样的活,那么下一样步就是需打开Mysql的缓缓查询日志来更为定位问题。MySQL
提供了徐查询日志,这个日志会记录有执行时间跨
long_query_time(默认是10s)的 SQL 及相关的信。

explain列的解释

若是打开日志,需要以 MySQL 的布置文件 my.cnf 的 [mysqld]
项下安排慢查询日志被,如下所示:

[mysqld]slow_query_log=1

key_len的计算

slow_query_log_file=/var/log/mysql/log-slow-queries.log

  1. 有着的索引字段,如果没有装not null,则要加一个字节。

  2. 定长字段,int占四只字节、date占三独字节、char(n)占n个字符。

  3. 对此变成字段varchar(n),则发n个字符+两只字节。

  4. 不同的字符集,一个字符占用的字节数不同。latin1编码的,一个字符占用一个字节,gbk编码的,一个字符占用少只字节,utf8编码的,一个字符占用三独字节。

long_query_time=2

3、建索引的几乎怪条件

以骨子里项目面临,由于变化的慢查询的日志可能会见特地酷,分析起来不是大

好,所以Mysql官方也提供了mysqldumpslow这个家伙,方便我们解析慢查询日志,感兴趣的同班可以活动到Mysql官方进行查看。

乃可能感兴趣之篇章:

SQL调优

些微SQL虽然出现于缓缓查询日志被,但不至于是彼自己的性质问题,可能是盖锁等待,服务器压力高等等。需要分析SQL语句实在的履行计划,而未是圈又履行同样总体SQL时,花费了不怎么日子,由自带的缓缓查询日志或者开源之暂缓查询系统稳定及具体的发题目的SQL,然后使用Explain工具来逐步调优,了解
MySQL
在履这长达数据经常之局部细节,比如是否开展了优化、是否利用了目录等等。基于
Explain 的回来结果我们不怕好因 MySQL
的行细节越分析是否合宜优化搜索、怎样优化索引。

有关索引的创办与优化原则,个人特别推荐美团点评技术集团的几点总结,讲得专程好,特地引用一下:

最荒唐前方缀匹配原则,非常重大的规则,mysql会一直于右侧匹配直到遇到范围查询(>、<、between、like)就终止匹配,比如a
= 1 and b = 2 and c > 3 and d = 4
如果建立(a,b,c,d)顺序的目,d是用无交目录的,如果成立(a,b,d,c)的目录则还足以就此到,a,b,d的逐一可以随便调整;

=和in可以乱序,比如a = 1 and b = 2 and c = 3
建立(a,b,c)索引可以肆意顺序,mysql的询问优化器会帮你优化成索引好分辨的款型;

尽量挑选区分度高的列作为索引,区分度的公式是count(distinct
col)/count(*),表示字段未另行的比重,比例越来越充分我们扫描的笔录数更是少,唯一键的区分度是1,而一些状态、性别字段可能于老数目面前区分度就是0,那也许有人会咨询,这个比重来什么经验值吗?使用状况不同,这个价值为充分为难确定,一般需要join的字段我们还务求是0.1之上,即平均1漫漫扫描10修记下;

索引列不克与计算,保持列“干净”,比如from_unixtime(create_time) =
’2014-05-29’就无克动用及目,原因特别简单,b+树中存的还是数表中的配段值,但进行搜时,需要将富有因素还施用函数才会于,显然成本不过怪。所以谈应该写成create_time
= unix_timestamp(’2014-05-29’);

尽可能的恢弘索引,不要新建索引。比如表中已经有a的目录,现在要是加(a,b)的目录,那么就待改原来的目录即可。

或多或少总

根据本文的思路,关于SQL慢查询的缓解得遵循以下的步调执行:

1.
开辟徐日志查询,确定是否生SQL语句占用了了多资源,如果是,在匪转移工作原意的前提下,对insert、group
by、order by、join等报告句进行优化。

  1. 设想调整MySQL的系参数:
    innodb_buffer_pool_size、innodb_log_file_size、table_cache等。

  2. 规定是否是盖高并发引起行锁的过期问题。

4.
使数据量过十分,需要考虑进一步的分库分表,可以瞻仰之前的文章1和文章2。

环视二维码或手动搜索微信公众号【架构栈】: ForestNotes

相关文章

标签:,

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图