explain的误解

发现MySQL的explain还是很有迷惑性的。

看下面两个sql的explain,(i,j)是tt的主键

mysql> explain select * from tt where i between 3 and 5 and j = 4\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tt
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: NULL
rows: 8
Extra: Using where; Using index
1 row in set (0.00 sec)

mysql> explain select * from tt where i > 2 and i < 6 and j = 4\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tt
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 8
Extra: Using where; Using index
1 row in set (0.00 sec)

看上去如果使用了between,那么MySQL可以用的索引的两列。但仔细的研究了一下,发现实际并不是这样。between 3 and 5可以写为(i>3 or i=3) and (i<5 or i=5),是这两个等号使用了两列,而大于和小于的判断仍然是index扫描,只用了一列。

再看另一个

mysql> explain select * from tt where i in (3,4,5) and j=4\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tt
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: NULL
rows: 3
Extra: Using where; Using index
1 row in set (0.00 sec)

这个才是真正用了两列,可以看到这里估计的行数是3,而刚才两个是8。用 show status 可以看得更清楚一些:

mysql> show status like 'handler_read%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Handler_read_first | 0 |
| Handler_read_key | 0 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 0 |
+-----------------------+-------+
6 rows in set (0.00 sec)

mysql> select * from tt where i in (3,4,5) and j=4;
+---+---+
| i | j |
+---+---+
| 3 | 4 |
+---+---+
1 row in set (0.00 sec)

mysql> show status like 'handler_read%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Handler_read_first | 0 |
| Handler_read_key | 4 |
| Handler_read_next | 1 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 0 |
+-----------------------+-------+
6 rows in set (0.00 sec)

mysql> select * from tt where i between 3 and 5 and j = 4;
+---+---+
| i | j |
+---+---+
| 3 | 4 |
+---+---+
1 row in set (0.00 sec)

mysql> show status like 'handler_read%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Handler_read_first | 0 |
| Handler_read_key | 6 |
| Handler_read_next | 10 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 0 |
+-----------------------+-------+
6 rows in set (0.00 sec)

后一个sql中有9次read_next_key,说明做了索引扫描。
131、高通骁龙影像平台总览:Spectra ISP 各代架构演进与特性对比 摘要:本文深入分析了高通骁龙Spectra ISP从250到780代的架构演进与技术痛点,揭示了各代关键改进与隐藏问题。重点剖析了双ISP带宽分配、AI ISP黑盒决策、温度控制等实战问题,并给出具体解决方案(如寄存器配置、QoS调整等)。文章强调工程师需平衡带宽、功耗与画质的三角关系,建议调试时先关闭AI模块建立基线,关注统计引擎配置,并建立温度监控机制。最后指出理解架构局限比追求完美设计更重要,需要针对不同场景找到合适的妥协方案。(148字) 阅读详情

相关推荐

Excel-MCP实战指南:零代码实现大模型与Excel的智能交互

本文详细介绍了Excel-MCP工具如何实现大模型与Excel的无缝交互,无需编写代码即可完成数据读写、图表生成等复杂操作。通过实战案例展示了Excel-MCP在销售报表自动化、财务对账等企业级场景中的应用,大幅提升工作效率。文章还提供了安装指南、核心功能解析和常见问题解决方案。

weixin_29212429的博客 433

MySQL之Explain各列详解-笔记

Explain各列详解 explain 语句执行后返回id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra列。 1、id列 id列的编号是select的序列号,有几个select就有几个id,并且id的顺序是按照select出现顺序增长的,MySQL将select查询分为简单查询(SIMPLE)和复杂查询(PRIMARY)。 复杂查询分为三类:简单子查询、派生表(from语句中的子查询)、union查询。 id列越大执行优先级越

T_chuxin的博客 2074

【49】Camunda8-Self-Managed部署之Docker方式

围绕camunda8 self-managed,介绍了基于Docker部署相关服务的过程。

AlieNeny的博客 1682

MySQL SELECT中LIMIT时EXPLAIN估算ROWS不准确的替代方法

在MySQL性能调试中,常常使用EXPLAIN解释MySQL执行计划,从而用来估算性能耗时。其中,rows用来表示在SQL执行过程中会被扫描的行数,该数值越大,意味着需要扫描的行数,相应的耗时更长。但是需要注意的是EXPLAIN中输出的rows只是一个估算值,不能完全对其百分之百相信,如EXPLAIN中对LIMITS的支持就比较有限。可以参考文章《MySQL EXPLAIN limits an

kiwi_coder 1万+

ns3-gym入门(二):linear-mesh例子详解

学习ns3-gym中关于IEEE 802.11网状网络中控制随机接入的例子linear-mesh

zoe2222226666的博客 1843

【无机纳米材料科研制图——OriginLab 0205】Origin对BET吸附/脱附曲线及孔径分布制图...

此篇,我们来分享如何对BET数据进行处理和制图。 一、等温吸脱附曲线绘制 1)找到等温吸脱附文件。 一半来说,对一个样品测一次BET,会产生很多数据,具体因仪器而异。我这里的数据主要有两个文件夹,一个脱附,一个吸附,吸附文件夹中多了一个等温吸脱附的文件夹。而这...

XD_Yangf的博客 803

MySQL总结(五)——Explain的坑以及如何分析SQL

本节主要回答以下4个小问题。 一、问题 1.explain真的准确吗?limit 100为什么会扫全表? 2.怎么确定走没走索引?怎么确定哪里耗时高? 3.走索引就一定耗时低吗? 4.order by desc 比正序慢吗? 二、SQL举例 举一个最近碰到的栗子,线上耗时偶尔飘高,于是乎分析了下 select source_id from table where a = 1...

waj89757的专栏 6306

从零到一:手把手教你用C# WinForms搭建工控上位机(含Panel控件布局与事件处理详解)

本文详细介绍了如何使用C# WinForms框架从零开始搭建工控上位机系统,重点讲解了Panel控件的布局技巧和事件处理机制。通过实战案例,帮助开发者掌握界面分区规划、动态窗体切换及数据通信等核心功能,适用于工业自动化监控系统的开发。

weixin_30321709的博客 609

mysql explain table_MySQL explain 应用详解(吐血整理)

什么是explain使用优化器可以模拟优化器执行SQL查询语句,从而知道MySQL怎么处理你的SQL语句的,分析你的查询语句和表结构的性能瓶颈。explain能够干什么读取表的顺序哪些索引能够被使用数据读取操作的操作类型哪些索引能够被实际使用表之间的引用每张表有多少行被物理查询创建一个学习用的数据库CREATE DATABASE /*!32312 IF NOT EXISTS*/`mydb` /*!...

weixin_32595533的博客 594

NE5532A与JRC4580在低噪声音频电路设计中的关键应用

本文深入探讨了经典运算放大器NE5532A与JRC4580在低噪声音频电路设计中的核心应用。文章从噪声模型分析入手,阐述了针对低阻抗信号源时,如何利用这两款BJT输入运放的低电流噪声特性进行优化设计。通过对比两者参数与实战守则,为设计高保真音频前级、耳机放大等电路提供了从原理图到PCB布局的完整低噪声解决方案。

weixin_29295541的博客 328

OnePlus救砖指南:线刷包与OTA全量包实战解析

本文详细解析了OnePlus手机救砖的两种核心方法:线刷包与OTA全量包。针对手机变砖的不同状况(如黑屏、能进Recovery等),文章提供了清晰的判断标准和对应的实战操作指南。重点阐述了线刷包作为终极救砖手段的底层原理与详细步骤,并对比了OTA全量包作为温和修复方案的使用场景与卡刷流程,旨在帮助用户安全、有效地恢复手机系统。

weixin_28312391的博客 1315

mysql 执行计划explain详解

explain主要是用来获取一个query的执行计划,描述mysql如何执行查询操作、执行顺序,使用到的索引,以及mysql成功返回结果集需要执行的行数。可以帮助我们分析 select 语句,让我们知道查询效率低下的原因,从而改进我们的查询,让查询优化器能够更好的工作。explain语法及描述从上面我们可以看到explain的语法是在select语句之前加上explain关键字就行了。然后在执行ex

carl.zhao的专栏 7732

华为OD机试 双机位A卷 - 流量波峰 (C++ & Python & JAVA & JS & GO)

华为OD机试双机位A卷 流量波峰,提供Java、C++、Python、Go、JavaScript源码实现,并提供完整思路讲解

qq_45776114的博客 1377

【MySQL】Explain字段的解释

Explain命令是查看查询优化器是如何决定执行查询的主要方法。这个功能有局限性,并不总会说出真相,但它的输出是可以获取的最好信息,值得花时间去了解,因为可以学习到查询是如何执行的。学会解释explain将会帮助你了解MySQL优化器是如何工作的。 Explain误区跟不足 在执行Explain时MySQL不会执行查询,这是一个误区。事实上查询中包括子查询,那么MySQL实际上会执行子查询,...

咔咔博客 741

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

Outlook Express 6 (OE6) for Win7/Win8/Win10

英文版 Outlook Express6.0, 兼容Win7/Win10/WinXP,解压就可用。

Understanding Explain Plan

Understanding Explain Plan Submitted by rleishman on Sun, 2007-02-18 03:31 SQL & PL/SQL Benjamin Disraeli, circa 1870 wrote:Never complai

t0nsha's Blog 1478

数学建模模型总结

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

mysql explain

mysql explain

AntHub的博客 399

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

理解Explain命令输出中的filesort

转自简朝阳:http://isky000.com/database/do-you-really-understand-filesort 前段时间看了 mysqlperformance blog 上一篇关于 filesort 的文章 ,看到 Percona 公司在招聘面试的时候常问应聘者“Explain 命令输出中的 filesort 的含义是什么”这个问题,而且基本上都得不到正确

qiuyepiaoling的专栏 740

MySQL执行计划解析与性能优化实战

数据库查询优化是提升系统性能的关键环节,其中执行计划分析作为核心技术手段,能够直观展示SQL语句的执行路径。通过EXPLAIN命令可以获取MySQL优化器选择的查询策略,包括索引使用情况、表连接顺序等核心信息。在工程实践中,合理利用索引合并、索引下推等特性,能显著提升查询效率。特别是在处理电商订单、分页查询等典型场景时,执行计划分析可以帮助开发者快速定位性能瓶颈。本文结合慢查询优化等实际案例,详解如何通过执行计划调优将响应时间从秒级降至毫秒级,为数据库性能优化提供实用解决方案。

weixin_33563728的博客 278

MySQL 联合索引最左匹配原则:全网结论都对吗?亲手实验纠正3个经典错误

本文通过实验验证了MySQL联合索引最左匹配原则的三个常见误区:1)WHERE条件顺序不影响索引使用,优化器会自动调整;2)跳过中间列不会使整个索引失效,最左列仍可用;3)范围查询后的列可通过索引下推过滤。文章强调理解原理比死记结论更重要,并提供了索引设计的最佳实践建议,包括常用列放最左、范围查询靠后等。所有实验基于MySQL 8.0,鼓励读者亲自验证而非盲目相信八股文。

那些看似不起波澜的日复一日,会在某天让你看到坚持的意义 498

关于Mysql的多列索引补充

关于Mysql的多列索引补充 补充 1.网络上查看的大部分都说:对于多列索引,只有访问了第一个列才会启用索引,如果访问后面的列则使用的是全表扫描。 补充:假如create INDEX index_a_name_date on a(name,date), 那么在select *from a where date=‘2021-02-20’ and name=‘张三’ 是索引有效的。只要有出现name,索引就是有效的,跟出现的顺序其实没啥太大关系,即使是select *from a where time= ‘’

weixin_43903627的博客 142

MySQL数据库 — Explain命令

这个信息有助于了解在执行查询时,存储引擎返回的记录数量与实际需要的记录数量之间的差距,从而优化查询性能。这让我们能够了解查询是如何被优化器处理的,查看各个步骤的详细信息,包括访问的表、使用的索引、行数估计等,从而帮助我们优化查询性能。通过 EXPLAIN 的输出,可以获取有关查询执行计划的详细信息,从而有助于优化和调试查询。功能:列出查询可能使用的索引。这将显示关于如何访问 employees 表的详细信息,包括使用的索引和扫描的行数等。这将展示连接操作的执行计划,包括每个表的访问方法和连接的具体细节。

m0_74293254的博客 1350

Mysql杂志(三十)——索引失效情况

本文分析了MySQL索引失效的常见情况及优化建议。主要失效场景包括:违反最左前缀原则、对索引列使用函数/计算、使用不等于(!=或<>)或NOT IN、LIKE通配符开头、隐式类型转换、OR连接非索引列等。文章还探讨了个人认为不会失效的情况(范围查询和SELECT *),并对比了四种EXPLAIN命令的功能差异。最后提供了优化方案,如使用UNION替代OR、避免类型转换、合理设计索引等,帮助开发者提升查询性能。

Java球球憋卷啦🥵 1012

mysql 一条语句能用到几个索引_mysql索引合并:一条sql可以使用多个索引-阿里云开发者社区...

前言mysql的索引合并并不是什么新特性。早在mysql5.0版本就已经实现。之所以还写这篇博文,是因为好多人还一直保留着一条sql语句只能使用一个索引的错误观念。本文会通过一些示例来说明如何使用索引合并。什么是索引合并下面我们看下mysql文档中对索引合并的说明:The Index Merge method is used to retrieve rows with several range ...

weixin_28950403的博客 2179

Hinglish AI翻译器中的解释功能优化分析

Hinglish AI翻译器中的解释功能优化分析 在Hinglish AI翻译器项目中,开发者发现了一个值得深入探讨的技术问题:当用户使用"Explain in Hinglish"功能来解释以疑问形式出现的Hinglish文本时,AI系统会错误地将解释请求误解为直接提问,导致输出结果不符合预期。 问题本质分析 该问题的核心在于自然语言处理中的意图识别偏差。系统当前的处理逻辑存在...

gitblog_07399的博客 546

用好EXPLAIN,再也不用凌晨三点改慢SQL

你有没有过这种时刻:对着一条慢SQL改了一下午,加了好几个索引,测试环境跑起来挺快,一上线性能反而更差了。你翻遍了SQL的每一个字符,怎么都找不到问题出在哪,最后只能对着监控里飙升的CPU使用率发呆。其实你离真相只差一步——从来没有真正读懂过EXPLAIN返回的执行计划。

Start_mswin的博客 753

Java面试中的技术陷阱与真实能力考察

Java作为企业级开发的核心语言,其技术栈深度与工程实践能力是面试考察的重点。从JVM内存模型到Spring框架原理,再到MySQL索引优化,每个技术点都涉及底层机制与最佳实践的结合。理解JVM的元空间取代永久代、掌握Spring的依赖注入原理、合理使用数据库索引,这些不仅是面试常见问题,更是日常开发中的必备技能。在分布式系统设计中,Redis的正确使用和分布式锁的实现方案尤为重要,避免出现数据一致性问题。通过真实面试案例可以发现,扎实的基础知识、系统的技术思维和解决问题的能力,远比死记硬背面试题更重要。

weixin_30550081的博客 355
上一篇: 如何编写MySQL的全文索引插件
下一篇: 使用load data infile时的字符集
epee
博客等级 码龄24年 2粉丝 0原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值