座谈SQL慢查询的解决思路

图片 1

目前,在运维部及DBA同事的协理和大家的共同努力下,对品种中的慢SQL举行了优化和更正,效果依旧很彰着的,在此给大家点一个大大的赞。为了让我们在SQL的处理上更为客观,形成可举办、可借鉴、可参照优化的方案,我在此地梳理一下慢SQL的解决思路,供我们参考。

慢SQL的系统表现

率先,我们怎样识别系统中遇见了SQL慢查询问题?个人觉得慢SQL有如下三个特征:

1,数据库CPU负载高。貌似是查询语句中有众多总计逻辑,导致数据库cpu负载。

2,IO负载高以致服务器卡住。以此貌似和全表查询没索引有关系。

3,查询语句正常,索引正常可是依然慢。倘使外部上索引正常,可是查询慢,需要探视是不是索引没有生效。

翻开SQL慢查询的日志

比方您的系统出现了上述意况,并且你不是用的阿里云的RDS这样的制品,那么下一步就需要开辟Mysql的慢查询日志来尤其定位问题。MySQL
提供了慢查询日志,那几个日志会记录所有执行时间超越long_query_time(默认是10s)的 SQL 及连锁的信息。

要拉开日志,需要在 MySQL 的布置文件 my.cnf 的 [mysqld]
项下安排慢查询日志开启,如下所示:

[mysqld]slow_query_log=1

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

long_query_time=2

在其实项目中,由于变化的慢查询的日记可能会专程大,分析起来不是很

惠及,所以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地图