快速定位线上慢 SQL 问题,掌握这几个性能排查工具可助你一臂之力

Posted IT学习日记

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了快速定位线上慢 SQL 问题,掌握这几个性能排查工具可助你一臂之力相关的知识,希望对你有一定的参考价值。



  • 💂 个人网站: IT知识小屋
  • 🤟 版权: 本文由【IT学习日记】原创、在CSDN首发、需要转载请联系博主
  • 💬 如果文章对你有帮助、欢迎关注、点赞、收藏(一键三连)和订阅专栏哦
  • 💅 开源项目:【轮子之王

文章目录

前言

  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 问题,掌握这几个性能排查工具可助你一臂之力

快速定位线上慢 SQL 问题,掌握这几个性能排查工具可助你一臂之力

线上慢查询的排查

一次MySQL线上慢查询分析及索引使用

一次MySQL线上慢查询分析及索引使用

线上服务CPU100%问题快速定位实战--转