更详细的执行计划 optimizer_trace

手把手教你认识OPTIMIZER_TRACE 前言 我们在日常维护数据库的时候,如果遇到慢语句查询的时候,我们一般会怎么做?执行EXPLAIN去查看它的执行计划? 是的。我们经常会这么做,然后看到执行计划展示给我们的一些信息,告诉我们MySQL是如何执行语句的。 BUT,执行计划往往只给我们带来了最基础的分析信息,比如是否有使用索引,还有一些其他供我们分析的信息,比如使用了临时表、排序等等。我们能从这些信息里面找一些优化点,这样就足... 阅读详情

目录

数据准备

查看 optimizer_trace


数据准备

CREATE TABLE `t2` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(11),
  `b` int(11),
  `c` varchar(16) ,
  `create_time` datetime,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

插入数据
for(int i=1; i< 10000; i++) {
    insert into t2(id, a, b, c, create_time) values(i, i, i%/1000, 'qweqwe', now())
}

查看 optimizer_trace

/* 打开optimizer_trace,只对本线程有效 */

SET optimizer_trace='enabled=on'; (set 后面加 global 则对所以线程有效)

执行sql select * from t2 where a < 10 and b < 100 and 1 = 1;

 /* 查看 OPTIMIZER_TRACE 输出 */

SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`\G;

输出内容如下

*************************** 1. row ***************************
QUERY: select * from t2 where a < 10 and b < 100 and 1 = 1   ### 执行的 sql 语句
TRACE: {
  "steps": [
    {
      "join_preparation": {      ### perpare 阶段
        "select#": 1,
        "steps": [
          {
            "expanded_query": "/* select#1 */ select `t2`.`id` AS `id`,`t2`.`a` AS `a`,`t2`.`b` AS `b`,`t2`.`c` AS `c`,`t2`.`create_time` AS `create_time` from `t2` where ((`t2`.`a` < 10) and (`t2`.`b` < 100) and (1 = 1))"
          }
        ]
      }
    },
    {
      "join_optimization": {   ### optimize 阶段
        "select#": 1,
        "steps": [
          {
            "condition_processing": {  ### 处理搜索条件
              "condition": "WHERE",
              "original_condition": "((`t2`.`a` < 10) and (`t2`.`b` < 100) and (1 = 1))",  ### 原始搜索条件
              "steps": [
                {
                  "transformation": "equality_propagation",  ### 等值判断处理
                  "resulting_condition": "((`t2`.`a` < 10) and (`t2`.`b` < 100) and (1 = 1))"
                },
                {
                  "transformation": "constant_propagation",  ### 等值传递替换
                  "resulting_condition": "((`t2`.`a` < 10) and (`t2`.`b` < 100) and (1 = 1))"
                },
                {
                  "transformation": "trivial_condition_removal", ### 去除无用条件,这里将 1 = 1 去掉了
                  "resulting_condition": "((`t2`.`a` < 10) and (`t2`.`b` < 100))"
                }
              ]
            }
          },
          {
            "substitute_generated_columns": {  ### 替换虚拟生成列
            }
          },
          {
            "table_dependencies": [  ### 表依赖信息
              {
                "table": "`t2`",
                "row_may_be_null": false,
                "map_bit": 0,
                "depends_on_map_bits": [
                ]
              }
            ]
          },
          {
            "ref_optimizer_key_uses": [
            ]
          },
          {
            "rows_estimation": [ ### 预估不用单表访问方式的访问成本
              {
                "table": "`t2`",
                "range_analysis": {
                  "table_scan": {  ### 全表访问方式
                    "rows": 9932,
                    "cost": 2085.5
                  },
                  "potential_range_indexes": [  ### 分析可能使用的索引
                    {
                      "index": "PRIMARY",
                      "usable": false,
                      "cause": "not_applicable"  ### applicable 的中文意思是,可适用的;可应用的;合适的
                    },
                    {
                      "index": "a",
                      "usable": true,
                      "key_parts": [
                        "a",
                        "id"
                      ]
                    },
                    {
                      "index": "b",
                      "usable": true,
                      "key_parts": [
                        "b",
                        "id"
                      ]
                    }
                  ],
                  "setup_range_conditions": [
                  ],
                  "group_index_range": {
                    "chosen": false,
                    "cause": "not_group_by_or_distinct"considered_execution_plans
                  },
                  "analyzing_range_alternatives": { ### 分析各种可能使用的索引的成本
                    "range_scan_alternatives": [
                      {
                        "index": "a",   ### 使用 a 索引
                        "ranges": [
                          "NULL < a < 10"
                        ],
                        "index_dives_for_eq_ranges": true, ### 计算查询成本 使用 index dive 的方式
                        "rowid_ordered": false, ### 使用该索引获取的记录是否按照主键排序
                        "using_mrr": false,     ### 是否使用 mrr 算法
                        "index_only": false,    ### 是否使用覆盖索引,fasle:没使用
                        "rows": 9,              ### 扫描行数
                        "cost": 11.81,          ### 查询成本
                        "chosen": true          ### 是否被执行计划选中,true 选中
                      },
                      {
                        "index": "b",
                        "ranges": [
                          "NULL < b < 100"
                        ],
                        "index_dives_for_eq_ranges": true,
                        "rowid_ordered": false,
                        "using_mrr": false,
                        "index_only": false,
                        "rows": 1000,
                        "cost": 1201,
                        "chosen": false,
                        "cause": "cost"     ### 因为成本太大而不选择该索引
                      }
                    ],
                    "analyzing_roworder_intersect": {  ### 分析索引合并的成本
                      "usable": false,
                      "cause": "too_few_roworder_scans"
                    }
                  },
                  "chosen_range_access_summary": {  ### 对于该 sql 最优的访问方法
                    "range_access_plan": {
                      "type": "range_scan",
                      "index": "a",
                      "rows": 9,
                      "ranges": [
                        "NULL < a < 10"
                      ]
                    },
                    "rows_for_plan": 9,
                    "cost_for_plan": 11.81,
                    "chosen": true
                  }
                }
              }
            ]
          },
          {
            "considered_execution_plans": [  ###?? 分析各种可能的执行计划(对于多表查询,可能有很多种不同的方案)
              {
                "plan_prefix": [
                ],
                "table": "`t2`",
                "best_access_path": {
                  "considered_access_paths": [
                    {
                      "rows_to_scan": 9,
                      "access_type": "range",
                      "range_details": {
                        "used_index": "a"
                      },
                      "resulting_rows": 9,
                      "cost": 13.61,
                      "chosen": true
                    }
                  ]
                },
                "condition_filtering_pct": 100,
                "rows_for_plan": 9,
                "cost_for_plan": 13.61,
                "chosen": true
              }
            ]
          },
          {
            "attaching_conditions_to_tables": { ### ?? 尝试给查询添加一些其他的查询条件
              "original_condition": "((`t2`.`a` < 10) and (`t2`.`b` < 100))",
              "attached_conditions_computation": [
              ],
              "attached_conditions_summary": [
                {
                  "table": "`t2`",
                  "attached": "((`t2`.`a` < 10) and (`t2`.`b` < 100))"
                }
              ]
            }
          },
          {
            "refine_plan": [ ### 在稍微改进下执行计划
              {
                "table": "`t2`",
                "pushed_index_condition": "(`t2`.`a` < 10)",
                "table_condition_attached": "(`t2`.`b` < 100)"
              }
            ]
          }
        ]
      }
    },
    {
      "join_execution": { ### execute阶段
        "select#": 1,
        "steps": [
        ]
      }
    }
  ]
}
MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0
INSUFFICIENT_PRIVILEGES: 0

MySQL的Query Execution Pipeline:如何通过trace文件(Optimizer Trace)深入理解执行过程? 客户端发起连接请求,MySQL服务器验证身份并建立连接。服务器接收到SQL语句后,进行词法分析和语法分析,检查语句的合法性。优化器根据统计信息、索引等,选择最佳的执行计划。按照优化器选择的执行计划,执行SQL语句,从存储引擎获取数据。将查询结果返回给客户端。其中,查询优化是整个过程中最复杂、最关键的环节。优化器的目标是找到成本最低的执行计划。决定哪些表先连接,哪些表后连接。选择使用哪些索引来加速查询。选择合适的连接算法,例如Nested Loop Join、Hash Join等。 阅读详情

相关推荐

Mysql:OPTIMIZER_TRACE详解

OPTIMIZER_TRACE是MySQL5.6引入的一个跟踪功能

知识改变命运,ヾ(◍°∇°◍)ノ゙【求关注】 2044

数据库监控与调优【五】—— OPTIMIZER TRACE详解

本文基于MySQL 8.0编写,理论支持MySQL 5.6及更高版本。OPTIMIZER_TRACE是MySQL 5.6引入的一项跟踪功能,它可以跟踪优化器做出的各种决策(比如访问表的方法、各种开销计算、各种转换等),并将跟踪结果记录到表中。

qq_46601365的博客 1247

基于51单片机扫地机器人(全套Proteus仿真+原理图+程序+说明书)

(内含源程序代码,原理图,仿真,讲解视频,元件清单等,【精品】值得推荐!!!扫地机器人是以单片机为主控制器。通过单片机控制小车行驶、除尘、蜂鸣。扫地机器人使用双电机驱动,以提高整车运动的平稳性;在智能车进驶过程中,采用双超声波模块实现避障。

2301_76434107的博客 1897

MySQL 调优 | OPTIMIZER_TRACE详解

OPTIMIZER_TRACE是MySQL 5.6引入的一项跟踪功能,它可以跟踪优化器做出的各种决策(比如访问表的方法、各种开销计算、各种转换等),并将跟踪结果记录到 INFORMATION_SCHEMA.OPTIMIZER_TRACE 表中。optimizer_trace总开关,默认值:enabled=off,one_line=offenabled:是否开启optimizer_trace;on表示开启,off表示关闭。one_line:是否开启单行存储。on表示开启;

ywl470812087的博客 969

STM32项目实战_基于STM32F103的智能药箱设计与实现(硬件详解+软件逻辑+调试要点)

本文详细介绍了基于STM32F103的智能药箱设计与实现,涵盖硬件设计、软件逻辑和调试要点。项目核心功能包括精准提醒、药品管理和远程监控,采用STM32单片机作为主控,结合光电开关、蓝牙模块等实现智能化管理。文章还分享了电路图设计、程序优化及常见问题解决方案,为嵌入式开发爱好者提供实用参考。

weixin_28717683的博客 306

国产谷歌地球,地形分析秒杀同款地图软件

咱们做地质、林业、水文、水利、电力、GIS、地图、水保、环境的,需要经常用到各种数据,比如影像、地形、矢量、模型等,但目前80%的规划大数据展示都离不开ArcGIS,令人头大的是很多朋友连ArcGIS软件安装起来都费劲。。。 那不会ArcGIS又装不了Google Earth怎么开展工作? 今天推荐大家一款国产免费专业地图浏览下载测量分析神器—图新地球 图新地球,国产三维gis软件。可以查看高清卫星影像地形以及其他很多常用电子地图,对地图需求的掌握远胜过Google Maps,而且上手比国外软件要简单

GISWorld3D的博客 3687

MySQL数据库调优————OPTIMIZER_TRACE详解

OPTIMIZER_TRACE

weixin_38910645的博客 1966

大疆前端开发面试题及参考答案(4万字长文)

在前端项目中,难点和性能优化的挑战无处不在。比如在处理复杂交互界面时,实现流畅的动画效果和实时反馈就是一大难点。当界面中有大量元素需要同时进行交互和动态更新,像电商平台的商品筛选和排序功能,不仅要保证操作的即时响应,还要确保界面在各种设备和网络环境下的稳定性,这就需要对事件处理、DOM 操作和数据更新机制有深入理解。在性能优化方面,首屏加载速度是常见的难点。当页面包含大量图片、脚本和样式文件时,如何合理地进行资源压缩、合并与缓存,以减少加载时间,是需要精心考虑的。

大模型大数据攻城狮的专栏 1155

MySQl查询分析工具 Optimizer Trace

OPTIMIZER_TRACE是MySQL 5.6引入的一项跟踪功能,它可以跟踪优化器做出的各种决策(比如访问表的方法、各种开销计算、各种转换等),并将跟踪结果记录到表中。EXPLAIN可以帮助您查看查询是否进行全表扫描,还是进行稍微优化的索引扫描。但EXPLAIN并没有真正告诉你MySQL为什么这样做。而Optimizer Trace旨在生成人类和程序可读的输出,以帮助理解MySQL优化器所做的决策和操作。

vonlinee的博客 1929

从矩阵理论角度理解偏最小二乘回归,以及在脑科学中(脑影像与行为、基因表达的关系)的应用举例

偏最小二乘法 (PLS) 是一种多元数据驱动的统计技术,旨在提取表示最大大脑行为关联的潜在变量(或潜在成分 latent components [LC])。

从事脑科学核磁共振方法学研究,在Nature communications等权威期刊发表研究论文,熟练掌握磁共振处理方法和统计学方法,欢迎大家和我交流。 975

lammps原子组速度的计算方法

在lammps摩擦、冲击、压痕等模拟过程中,涉及到某个原子组的整体移动,如果要输出这个原子组的整体移动速度,可以使用vcm()函数。下面是一个具体的使用案例,金刚石球在盒子内移动,输出移动过程中金刚石球在x方向的质心速度。vcm()是lammps自带的一个函数,返回原子组质心在设定方向的速度。其中,ID为group-ID,dim为方向,可设置x、y或者z方向。大家好,我是小马老师。

lammps_jiayou的博客 343

mysql慢sql分析工具OPTIMIZER_TRACE

我们在日常维护数据库的时候,如果遇到慢语句查询的时候,我们一般会怎么做?执行EXPLAIN去查看它的执行计划? 是的。我们经常会这么做,然后看到执行计划展示给我们的一些信息,告诉我们MySQL是如何执行语句的。 BUT,执行计划往往只给我们带来了最基础的分析信息,比如是否有使用索引,还有一些其他供我们分析的信息,比如使用了临时表、排序等等。我们能从这些信息里面找一些优化点,这样就足够了吗? 看看这张图里的执行计划,我们可以提很多问题:为什么t2表上明明使用了索引在Extra列中还是能看到temp

雅冰石的专栏 836

【WRF-Urban数据集】中国60个城市的1 km分辨率城市冠层参数(UCPs)

中国60个城市的1 km分辨率城市冠层参数(UCPs)

WW、forever的博客 1069

mysql通过trace分析优化器如何选择执行计划

在我们调优MySQL的SQL时候,通常使用explain进行查看sql的执行计划。至于优化器为什么会这样选择,就无从得知。如果你想了解为什么,那么可以通过trace文件能够进一步了解为什么优化器选择A执行计划而不选择B执行计划.帮助我们更好的理解优化器的行为. 打开trace,并设置格式为Json SET OPTIMIZER_TRACE=“enabled=on”,END_MARKERS_IN_J...

chenlvzhou的专栏 1038

AUTOSAR进阶图解==>AUTOSAR_SWS_ADCDriver

本文深入解析了AUTOSAR ADC Driver的架构设计和技术实现。主要内容包括:1)ADC Driver在AUTOSAR分层架构中的定位及核心功能;2)详细的模块架构设计,涵盖初始化管理、组转换管理、优先级处理等核心子组件;3)全面的配置模型说明,包括主配置类、通用配置、通道配置等关键数据结构;4)状态机机制和操作序列分析。通过分层设计和标准化接口,ADC Driver实现了硬件抽象和软件解耦,提供了良好的可移植性和可维护性。

一名留德华的,康德的信徒的,专注于汽车电子领域的博客 789

数学建模模型总结

这是本人在两年内准备参加数学建模竞赛搜集到的模型资料,已经经过了本人的筛选和整理,希望能够对准备参加数学建模竞赛的学弟学妹们提供一些帮助!

oracle执行计划remote,最权威Oracle获取SQL语句执行计划大全

该文档为根据相关资料整理、总结而成,主要讲解Oracle数据库中,获取SQL语句执行计划的最权威、最正确的方法、步骤,此外,还详细该文档为根据相关资料整理、总结而成,主要讲解Oracle数据库中,获取SQL语句执行计划的最权威、最正确的方法、步骤,此外,还详细说明了每种方法中可选项的意义及使用方法,以方便大家和自己日常工作中查阅使用。1、查询v$sql_plan:SQL> col "Quer...

weixin_29628611的博客 1001

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

Oracle 10053 事件

一. 10053事件 当一个SQL出现性能问题的时候,可以使用SQL_TRACE 或者 10046事件来跟踪SQL. 通过生成的trace来了解SQL的执行过程。   Oracle SQL Trace 和 10046 事件 http://blog.youkuaiyun.com/tanzuai/article/details/42458091   Event 10053 执行计划 绑定变量 Bi

让 学习 成为一种 习惯 ( 谭祖爱 & 技术博客 ) 1082

android 蓝牙通讯demo

android 下蓝牙通讯demo,实现了发现蓝牙,使能蓝牙,通过蓝牙发送消息。

mysql between和in_mysql between and、>=<=、in性能实例分析

首先向大家介绍mysql between and、>=<=和in关键字在where查询中的使用方法和实例。mysql between and用法BETWEEN 运算符用于 WHERE 表达式中,选取介于两个值之间的数据范围。除了数值类型外,BETWEEN 也支持字符串范围。BETWEEN 同 AND 一起搭配使用,语法如下:WHERE column BETWEEN value1 AND...

weixin_27015375的博客 3211

mysql sql优化学习笔记

MySQL数据库的sql优化 优化sql步骤 查询sql执行频率 show status like 'Com_______'; -- 查看全部的 show status like 'Innodb_rows_%'; -- 查看innodb的 定位低效sql 慢查询日志 : 通过慢查询日志定位那些执行效率较低的 SQL 语句,用–log-slow-queries[=file_name]选项启动时,mysqld 写一个包含所有执行时间超过 long_query_time 秒的 SQL 语句的日志文件。具体可

ITxiaobaimrLIU的博客 148

Mysql性能优化

Mysql性能优化相关

weixin_45322869的博客 302

MySQL高级第六篇:数据库性能分析与优化

1.观察服务器状态,看是否存在周期性波动,是的话可以尝试加缓存或者调整缓存失效策略;2.否则考虑开启慢查询日志,找出比较慢的SQL语句;3.分析SQL语句:EXPLAIN,SHOW PROFILE4.如果是因为SQL等待时间比较长,考虑调整服务器参数;5.如果是因为SQL执行时间比较长,考虑优化索引、SQL语句本身或者表设计;6.如果以上都不能解决,考虑是否SQL查询达到瓶颈7.这时需要考虑读写分离,分库分表等。定位了查询慢的SQL之后,就可以。

I wanna be myself, where I Belong. 926

optimizer trace 查看Mysql如何选择执行计划的过程

前面几篇讲了Mysql基于成本的优化,也看了执行计划,今天我们来看看Mysql提供的更详细的执行计划生成过程。 optimizer traceoptimizer trace由来:optimizer trace的使用方式:optimizer trace实践:小结 optimizer trace由来: 1、我们平时查看SQL的执行计划,但是执行计划是相对粗略的,只告诉你使用了什么索引,采用了什么方式。但是没有告诉你它为什么选择这种查询方式。 2、所以,在MySQL 5.6之后,提供了个optimizer tra

疯狂的蜗牛 1077

深入 MySQL 查询优化器:Optimizer Trace 分析

MySQL的Optimizer Trace功能用于深入分析SQL查询的优化过程,帮助开发者理解查询执行计划的选择。该功能默认关闭,因为开启后可能导致约10%的性能下降。Optimizer Trace通过三个主要阶段(join_preparation、join_optimization、join_execution)详细记录SQL语句的准备、优化和执行过程。在优化阶段,系统会评估不同索引和扫描方式的成本,选择最优执行计划。通过调整相关参数(如optimizer_trace_enabled、optimizer_

Eucalyptus's blog 1544

MySql中执行计划如何来的——Optimizer Trace

当谈到MySQL的执行计划时,会有很多同学想:“我就觉得使用其他的执行方案比EXPLAIN语句输出的方案强,凭什么优化器做的决定与我得不一样?”。这个问题在MySQL 5.6之前或许自己很难解决,但是现在MySQL5.6及更高的版本中引入了Optimizer Trace。

山四的博客 426

MySql中执行计划如何来的——Optimizer Trace | 京东云技术团队

当谈到MySQL的执行计划时,会有很多同学想:“我就觉得使用其他的执行方案比EXPLAIN语句输出的方案强,凭什么优化器做的决定与我得不一样?”。这个问题在MySQL 5.6之前或许自己很难解决,但是现在MySQL5.6及更高的版本中引入了Optimizer Trace。

JDDTechTalk的博客 650

MYSQL 执行计划分析三看, EXPLAIN,PROFILING,OPTIMIZER_TRACE

MYSQL 执行计划分析三看, EXPLAIN,PROFILING,OPTIMIZER_TRACE step 1 使用explain 查看执行计划, 5.6后可以加参数 explain format=json xxx 输出json格式的信息 step 2 使用profiling详细的列出在每一个步骤消耗的时间,前提是先执行一遍语句。 #打开profiling 的设置 ...

Jaylon Wang的专栏 380
上一篇: mysql是如何选择索引的(为什么会选错索引)
下一篇: innodb存储引擎之:索引的数据结构
三易的博客
博客等级 码龄15年 42粉丝 89原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值