MySQL查询性能优化武器之链路追踪

 更新时间:2022年08月08日 08:38:31   作者:一灯架构​​​​​​​  
这篇文章主要介绍了MySQL查询性能优化武器之链路追踪,optimizer trace优化器追踪,可以帮助我们查看优化器生成执行计划的整个过程,以及做出的各种决策,包括访问表的方法、各种开销计算、各种转换等

前言

MySQL优化器可以生成Explain执行计划,我们可以通过执行计划查看是否使用了索引,使用了哪种索引?

但是到底为什么会使用这个索引,我们却无从得知。

好在MySQL提供了一个好用的分析工具 — optimizer trace(优化器追踪),可以帮助我们查看优化器生成执行计划的整个过程,以及做出的各种决策,包括访问表的方法、各种开销计算、各种转换等。

1. 查看optimizer trace配置

show variables like '%optimizer_trace%';

输出参数详解:

optimizer_trace 主配置,enabled的on表示开启,off表示关闭,one_line表示是否展示成一行

optimizer_trace_features 表示优化器的可选特性,包括贪心搜索、范围优化等

optimizer_trace_limit 表示优化器追踪最大显示数目,默认是1条

optimizer_trace_max_mem_size 表示优化器追踪占用的最大容量

optimizer_trace_offset 表示显示的第一个优化器追踪的偏移量

2. 开启optimizer trace

optimizer trace默认是关闭,我们可以使用命令手动开启:

SET optimizer_trace="enabled=on";

3. 线上问题复现

先造点数据备用,创建一张用户表:

CREATE TABLE `user` (
  `id` int NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(100) NOT NULL COMMENT '姓名',
  `gender` tinyint NOT NULL COMMENT '性别',
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`),
  KEY `idx_gender_name` (`gender`,`name`)
) ENGINE=InnoDB COMMENT='用户表';

创建了两个索引,分别是(name)和(gender,name)。

执行一条SQL,看到底用到了哪个索引:

select * from user where gender=0 and name='一灯';

跟期望的一致,优先使用了(gender,name)的联合索引,因为where条件中刚好有gendername两个字段。

我们把这条SQL传参换一下试试:

select * from user where gender=0 and name='张三';

这次竟然用了(name)上面的索引,同一条SQL因为传参不同,而使用了不同的索引。

到这里,使用现有工具,我们已经无法排查分析,MySQL优化器为什么使用了(name)上的索引,而没有使用(gender,name)上的联合索引。

只能请今天的主角 —optimizer trace(优化器追踪)出场了。

3. 使用optimizer trace

使用optimizer trace查看优化器的选择过程:

SELECT * FROM information_schema.OPTIMIZER_TRACE;

输出结果共有4列:

QUERY 表示我们执行的查询语句

TRACE 优化器生成执行计划的过程(重点关注)

MISSING_BYTES_BEYOND_MAX_MEM_SIZE 优化过程其余的信息会被显示在这一列

INSUFFICIENT_PRIVILEGES 表示是否有权限查看优化过程,0是,1否

接下来我们看一下TRACE列的内容,里面的数据很多,我们重点分析一下range_scan_alternatives结果列,这个结果列展示了索引选择的过程。

输出结果字段含义:

  • index 索引名称
  • ranges 查询范围
  • index_dives_for_eq_ranges 是否用到索引潜水的优化逻辑
  • rowid_ordered 是否按主键排序
  • using_mrr 是否使用mrr
  • index_only 是否使用了覆盖索引
  • in_memory 使用内存大小
  • rows 预估扫描行数
  • cost 预估成本大小,值越小越好
  • chosen 是否被选择
  • cause 没有被选择的原因,cost表示成本过高

从输出结果中,可以看到优化器最终选择了使用(name)索引,而(gender,name)索引因为成本过高没有被使用。

再也不用担心找不到MySQL用错索引的原因,赶紧用起来吧!

到此这篇关于MySQL查询性能优化武器之链路追踪的文章就介绍到这了,更多相关MySQL链路追踪内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • MySQL慢查询优化解决问题

    MySQL慢查询优化解决问题

    这篇文章主要介绍了MySQL慢查询优化解决问题,MySQL的慢查询,全名是慢查询日志,是MySQL提供的一种日志记录,用来记录在MySQL中响应时间超过阀值的语句,下文详细介绍慢查询的调优情况,需要的小伙伴可以参考一下
    2022-03-03
  • mysql prompt一个特别好用的命令

    mysql prompt一个特别好用的命令

    本篇文章是对mysql中的prompt进行了详细的分析介绍,需要的朋友参考下
    2013-06-06
  • MySQL之MyISAM存储引擎的非聚簇索引详解

    MySQL之MyISAM存储引擎的非聚簇索引详解

    这篇文章主要为大家详细介绍了MySQL之MyISAM存储引擎的非聚簇索引,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下,希望能够给你带来帮助
    2022-03-03
  • MySQL递归查找树形结构(这个方法太实用了!)

    MySQL递归查找树形结构(这个方法太实用了!)

    对于数据库中的树形结构数据,如部门表,有时候,我们需要知道某部门的所有下属部分或者某部分的所有上级部门,这时候就需要用到mysql的递归查询,下面这篇文章主要给大家介绍了关于MySQL递归查找树形结构的相关资料,需要的朋友可以参考下
    2022-11-11
  • MySQL5.5版本安装与安装失败详细讲解

    MySQL5.5版本安装与安装失败详细讲解

    MySQL是一款安全、跨平台、高效的,并与PHP、Java等主流编程语言紧密结合的数据库系统,下面这篇文章主要给大家介绍了关于MySQL5.5版本安装与安装失败详细讲解的相关资料,需要的朋友可以参考下
    2023-03-03
  • MySQL大小写敏感的注意事项

    MySQL大小写敏感的注意事项

    MySQL 在 Windows 下不区分大小写,但在 Linux 下默认是区分大小写。如果你稍加不注意就会出现在本机开发的程序运行一切正常,发布到服务器行就出现表名找不到的问题,一头雾水。
    2021-05-05
  • 在centos7下安装和部署java8和mysql

    在centos7下安装和部署java8和mysql

    一般学习java和部署项目都是在本地部署,但是生产环境一般都是在linux环境下,部署和安装环境都是在控制台下进行操作的,没有windows的可视化的操作界面,对与linux的命令掌握和操作对小白来说都是一个个挑战,记录下自己的安装配置过程
    2017-04-04
  • MySQL聚合查询案例讲解

    MySQL聚合查询案例讲解

    这篇文章主要介绍了MySQL聚合查询案例讲解,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2023-03-03
  • MySQL 数据类型 大全

    MySQL 数据类型 大全

    mysql下的一些数据类型,后面附有类型的说明。
    2009-04-04
  • mysql定时任务(event事件)实现详解

    mysql定时任务(event事件)实现详解

    这篇文章主要介绍了mysql定时任务(event事件)实现详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
    2019-08-08

最新评论