快速定位线上慢 SQL 问题,掌握这几个性能排查工具可助你一臂之力
Posted IT学习日记
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了快速定位线上慢 SQL 问题,掌握这几个性能排查工具可助你一臂之力相关的知识,希望对你有一定的参考价值。
文章目录
前言
mysql性能优化是一个老生常谈的问题,无论是在实际工作中还是面试中,都不可避免遇到相应的场景,下面博主就总结一些能够帮助大家解决这个问题的小技巧,主要划分为性能优化工具和性能优化技巧两大模块。
SQL性能优化工具
在进行SQL优化之前首先需要确认哪些SQL需要优化,这时就需要使用到SQL性能分析工具,平常工作业务中,主要优化的是查询语句。
一、SQL的执行频率
SQL性能优化一般是针对查询语句,所以在定位是否需要优化之前,可以先确认表的更删查改的一个执行频率对比,如果是查询占主导地位,则可以一步排查。
MySQL支持客户端通过:show [session|global] status命令对服务器状态进行查询。
查看执行频率方式:
- show global status like ‘com_______’(7个下划线,表示后面会有7个字符)
二、慢查询日志
确认了SQL的执行频率,则需要通过慢查询日志进行进一步定位哪些SQL语句执行时间占用较长。
慢查询日志记录了所有执行时间超过指定参数(long_query_time,单位:秒,默认是10s)的所有SQL语句的日志。
默认情况下,慢查询日志是没有开启的,需要在MySQL的配置文件(linux下默认路径为:/etc/my.cnf)中配置如下指令:
-
查询服务端是否开启慢查询日志:show variables like ‘slow_query_log’;
-
在mysql的配置文件中添加如下配置启动:
-
1、slow_query_log=1;开启mysql慢日志查询开关
-
2、long_query_time=xx;设置慢日志时间,只要SQL执行时间查过该值,则视为慢查询,记录在慢日志中。
-
配置完成后重启mysql服务端
-
linux中mysql的慢日志文件在: /var/lib/mysql/localhost-slow.log
-
window可以在my.ini文件中配置具体的地址,示例如下:
执行结果示意图:
参数具体含义如下:
-
Query_time:表示 SQL执行的时间,越长则越慢
-
Lock_time:表示在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间
-
Rows_sent:表示查询返回的行数
-
Rows_examined:表示查询检查的行数
三、show profiles详情分析
通过慢查询日志,我们可以定位到超过设置阈值的慢SQL,但是实际业务中,这并不能完全具有代表性,因为阈值是主观设置的,可能有大量执行时间低于阈值的SQL也存在问题,因此慢日志SQL并不能完全定位出所有的慢SQL,此时则需要借助新的工具: show profiles。
show profiles 能够让我们了解到SQL执行时时间都耗费到哪里了。 通过have_profiling参数,可以查看mysql是否支持该profile操作。
- 格式: select @@have_profiling;
默认情况下,profiling是关闭的,可以同set指令开启session|global级别的profiling。
- 格式: set global | session profiling = 1;
优化方案:
- show profiles:查看每一条SQL的耗时基本情况
- show profile for query query_id:查询指定query_id的SQL语句各个阶段的耗时情况
- show profile cpu for query query_id:查询指定query_id的SQL语句cpu使用情况
四、explain执行计划
前面介绍的几种方式都是通过执行时间长短来判断SQL语句执行的性能好坏,但是这个相对来说是比较片面的,想要更全面地评判SQL语句好坏,则需要使用explain查看SQL的执行计划。
Explain或者DESC命令获取MySQL如何执行SELECT语句的信息,包括在SELECT语句过程中表如何连接和连接的顺序。
- 语法:explain | desc select xxxx…
1、ID参数
select中的查询序号,表示的是查询中执行select子句或者是操作表的顺序(id相同,执行顺序从上往下,id不同,值越大,越先执行)
2、select_type参数
表示select查询类型,常见的有SIMPLE(简单表,即不使用表连接或者子查询)、primary(主查询,即外层查询)、UNION(UNION中的第二个或者后面的查询语句)、SUBQUERY(SELECT/WHERE之后包含了子查询)
3、type参数
表示连接/访问类型,性能由好到差的连接类型为:null、system、const、eq_ref、ref、range、index、all
在优化的时候,尽量将type往前优化,最差也要为index
- null:查询的时候不访问任何表,如:select “1”
- system:当访问一些系统表的时候会出现
- const:根据主键或者唯一索引访问时,会出现const
- eq_ref:类似ref,区别就在使用的索引是唯一索引,对于每个索引键值,表中只有一条记录匹配,简单来说,就是多表连接中使用primary key或者 unique key作为关联条件
- ref:使用非唯一性索引进行访问时,可能出现ref
- range:使用索引进行范围查询时
- index:使用到了索引,但是对整个索引都进行了遍历,性能也比较差
- all:全表扫描,性能最差
4、possible_key参数: 显示在执行查询时,表中可能被使用到的索引,一个或者多个、
5、key参数: 在执行查询时,实际上会命中的索引
6、key_len参数: 表示使用到的索引的字节数,该值为索引字段最大可能长度,在不损失精确性的前提下,长度越短越好。
7、rows参数: MySQL认为必须要执行查询的行数,在innodb引擎表中,是一个估计值,可能并不总是准确的
8、ref参数: 哪些列或者常量被用作索引列上的值(如下图:图源网络,侵联删)
9、filtered参数: 表示查询返回的行数占总读取行数的百分比,值越大越好
10、extra参数: 额外的一些执行信息如排序
性能优化技巧
学习完如何使用调优工具定位需要优化的SQL后,下面就来认识SQL的增、删、查、改进行优化技巧吧。
一、插入数据优化
插入数据的优化点:主要在于最大程度上利用每一次数据库连接,避免频繁创建数据连接,因此,常见的优化方式如下:
-
批量插入(单条插入需要每次都与数据创建链接,存在比较大消耗)
-
手动管理事务(可以将批量多个批量插入放在一个事务中,减少开启、关闭事务次数)
-
数据按照主键顺序插入(避免页分裂和重新指针指向,下面会具体介绍这两者的概念)
-
大数据量时使用load指令(如初始化时需要几百甚至上千万数据(百万数据十几秒),此时则使用load命令来进行插入数据,mysql原生支持大数据量插入,性能非常高)
load命令的使用:
-
如果是命令行连接,需要指定客户端需要执行本地文件,在连接中添加:–local-infile
-
服务端开启load指令支持:set grobal local_infile=1
-
语法:load data local infile ‘文件路径’ into table ‘表名’ fields teminated by ‘字段分割符号’ lines teminated by ‘行分割符号’
主键优化
数据组织方式:
在MySQL的InnoDB引擎中,表数据都是根据主键顺序组织存放的,这种存储方式的表称为索引组织表(Index Organized Table IOT),相关概念如下:
页(Page): 存放的就是具体的行数据
特点: 页可以为空、也可以填充一半,或者填充100%。每个页包含了2-N行数据(如果一行数据太大,会行溢出),页中数据根据主键排序【InnoDB中规则每个页中至少大于2行,如果只有一行,证明形成了链表,在innodb中是允许的】。页与也之间存在指针相互指向。
页分裂:
如果插入数据是数据的主键时乱序插入,因为InnoDB中数据是按照主键的顺序存放在页中的,它会找到本应该插入的数据页50%的位置(该数据页因为乱序插入已经满了),然后将之后的元素以及新插入的元素放到新申请的页中。然后指针重新指向的现象。
页合并:
注意: 在InnoDB中,当删除一个记录时,实际上记录并没有被物理删除,知识记录被标记(flaged)为删除,并且它的空间变得允许被其他记录声明使用。
定义: 当页中数据被删除到MERGE_THRESHOLD(默认是页的50%),InnoDB会开始寻找最靠近的页(前或后)看看是否可以将两个页合并以优化空间使用。
MERGE_THRESHOLD参数在创建表或者索引时可以进行指定,默认就是页的一半。
主键设计原则:
-
满足业务需求情况下,尽量降低主键的长度(因为二级索引叶子节点存储的是主键值,主键值越长,占用的空间越大,在搜索时需要耗费磁盘IO的次数就越多)
-
插入数据时,尽量顺序插入,选择使用AUTO_INCREMENT自增主键(乱序插入可能导致页分裂,消耗性能)
-
尽量不要使用UUID做主键或者其他自然主键如身份证(因为它们是无序的,还是会存在页分裂,同时因为它们的长度也较长,在检索时会耗费大量的磁盘IO)
-
业务操作时,尽量避免对逐渐的修改(修改了主键,需要重新维护对应的索引数据结构)
二、查询优化
1、Order by优化
使用explain关键字查看SQL语句的执行计划,注意:出现Using index的前提时走了覆盖索引,多字段排序时,也遵循最左前缀法则。
1、Using filesort: 通过表的索引或全表扫描,读取满足条件的数据行,然后在排序缓存区sort buffer中完成排序操作。所有不是通过索引直接返回排序结果的排序都叫Filesort排序。
2、Using index: 通过有序索引顺序扫描直接返回有序数据,这种情况称为using index,它不需要额外排序,操作效率高。
3、Backward index scan;Using index: 没有进行额外排序,但是进行了反向扫描索引。
4、Using index;Using filesort: 没有直接通过索引返回有序数据,需要走过sort buff进行排序,效率也是较低。
Using filesort优化方式:
-
给对应的字段创建联合索引(注意要根据排序的顺序或者倒叙指定索引的顺序)
-
如果不可避免出现filesort,在对大数据量排序时,可以释放增加排序缓冲区大小sort_buffer_size(默认是256K),查询方式:show variables like ‘sort_buffer_size’。
-
如果排序缓冲区被占满,则会在磁盘进行排序操作,性能会降低
2、group by优化
分组操作中,主要是索引起了优化效果。使用explain关键字查看SQL语句的执行计划分组情况如下:
-
Using temporary: 使用了临时表,性能较低
-
Using index: 走了索引,性能提高(案例:group by 和where中字段满足最左前缀法则)
-
Using index;Using temporary:案例如不遵循最左前缀法则,但是命中索引覆盖时,可能出现这个值
优化技巧: 通过索引来提高效率,注意是否满足最左前缀法则
3、Limit优化
现象: 在大数量时分页时,越往后的数据,需要耗时越大,效率越大
优化: 子查询(多表关联) + 覆盖索引
方式: 先查询到需要筛选数据的主键,然后再进行数据子查询或者表关联查询到需要的具体数据
4、Count优化
这个话题已经是老生常谈了,但是总有人争论不休,其实,最优权威的是官方的说法,官方是推荐使用count(*)而不是其他,下面来认识各种count用法的一个区别。
MyISAM引擎会把一个表中的总行数存储到磁盘中,在执行count(*)不带where条件时,可以直接拿到该数据,效率很高。
InnoDB在count时,需要将数据一行行从引擎读取出来,然后累计计数(大数量的情况下是比较耗时的,主要是由存储引擎决定的)。
优化思路:借助内存数据库手动维护总条数,插入时加1,删除时减1等
count的用法:
-
count(*): 对返回的数据进行计数。逻辑:引擎做了专门优化,不取值,服务层直接按行进行累加。
-
count(主键):主键不可能为NULL,InnoDB会遍历全表、将每行的主键ID取出来,返回给服务层进行累计操作,无需判断是否为NULL。
-
count(1):对返回的每条数据都置1,然后进行累计。逻辑:引擎遍历全表,但是不取值,服务层对返回的每一行都放一个数字"1"进去,直接进行累加操作。
-
count(列):统计字段值不为NULL的条数。统计逻辑:没有not null约束,idb引擎会遍历全表的每一行的字段值取出来,返回给服务层,服务层会判断是否为null,不为null则进行累加。如果有not null约束,则引擎会遍历全表返回每一行的字段值,返回给服务层,服务层直接进行累加操作。
推荐使用:count(*)
Update语句优化
更新数据时where条件一定要使用索引字段,否则就会从行锁升级为表锁,并发情况下,性能降低。
删除语句优化
跟插入语句类似,要利用批量删除的方式,最大程度减少数据库连接,事务提交的消耗。
写在最后
道理千遍,不如实践。性能优化更多的是结合理论的基础上进行亲自实践,这样才能够在众多的方式中找到符合的方式,希望本篇文章能够给大家一些启发,如果文章对你有帮助,欢迎给博主点赞、关注。
博主最近开源了一个名为“轮子之王”的项目,其中集成了开发中常用的各项功能(现已集成有:csv、excel、ftp、文件服务器等导入导出轮子),有兴趣的小伙伴可以通过下面的地址跳转看看,希望能够帮助大家提高开发效率。
Gitee地址: 轮子之王
Github地址: 轮子之王
以上是关于快速定位线上慢 SQL 问题,掌握这几个性能排查工具可助你一臂之力的主要内容,如果未能解决你的问题,请参考以下文章
快速定位线上慢 SQL 问题,掌握这几个性能排查工具可助你一臂之力