MySQL:explain结果中Extra:Impossible WHERE noticed after reading const tables问题
前情提要
上午有同事突然找我，向我反馈说在对MySQL中的语句进行explain解析的时候，explain的结果中table、type、possible_keys、key等关键性字段都是空的，什么信息都得不到，而当把其中一个字段phone，类型是varchar的单引号去掉了之后，也就是说把where phone='13800138000' 改为where phone=13800138000之后，再执行explain就能得到explain的关键性字段的结果了。
这个就让我很纳闷，不合常理啊，字段的隐式转换正常来说这种情况应该会导致索引失效才对啊，现在竟然是反之生效，刷新了我们的认知。
我就说了下面一句话：
一个不合常理的现象往往都是由于一个不起眼的或者平时被我们忽略的点所造成的
出现的情况
这种非常理所能解释通的现象，引起了我的好奇心。
从上图中看到Extra：Impossible WHERE noticed after reading const tables，字面上的意思是：读取const tables表之后，没有发现匹配的行。
其实，这个跟MySQL的版本有关，在 MySQL 5.7.17 下的执行结果中可以发现同样的表结构、同样的数据、同样的查询语句，Extra 中的显示的内容为“no matching row in const table”，这句话理解起来就容易多了。
原因
产生“ Impossible WHERE noticed after reading const tables”的原因是这样的，MySQL在 EXPLAIN 之前会优先根据这一条件查找出对应的记录，并用记录的实际值替换查询中所有使用到的该表属性。
这是因为满足以下四个条件时，就会使得针对该表的查询最多只能产生一条命中结果，在该表无法命中数据的情况下就会提示“在 const table 表中没有找到匹配的行”，而这个 “const table”就指的是满足下面四个条件的表。
这是 MySQL 的一个优化策略。
- 当查询条件中包含了某个表的主键或者非空的唯一索引列
- 该列的判定条件为等值条件
- 目标值的类型与该列的类型一致
- 目标值为一个确定的常量
而我们的这张表user_info的这个查询语句刚好符合这4个条件，原因：
1、phone是非空的唯一索引列；
2、phone= '13800138000’是等值条件
3、phone是字符串类型，'13800138000’也是字符串类型
4、13800138000是一个确定的常量
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。
相关文章
数据库备份是防止数据丢失的一种重要手段,生产环境中,数据的安全性是至关重要的,任何数据的丢失都可能产生严重的后果,所以本文给大家介绍了mysql定时备份shell脚本和还原的实例,需要的朋友可以参考下2024-02-02
在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。本文我们就聊聊MYSQL的优化2021-09-09
在本文里我们给大家分享了关于mysql varchar类型求和实例操作以及相关知识点，需要的朋友们学习参考下。2019-03-03
这篇文章主要介绍了mysql索引失效的5种情况分析,需要的朋友可以参考下2015-01-01
编绎MySQL时一般以ISO-8859字符集作为默认的字符集，因此在比较过程中中文编码字符大小写转换造成了这种现象，一种解决方法是对于包含中文的字段加上"binary"属性，使之作为二进制比较2011-11-11
这篇文章主要介绍了mysql函数日期和时间函数汇总，日期和时间函数主要用来处理日期和时间值，一般的日期函数除了使用date类型的参数外，也可以使用datetime或者timestamp类型的参数，但会忽略这些值的时间部分2022-07-07
在mysql中是没有top关键字的，不过可以用limit来完成此功能，下面举例为大家详细介绍下它的使用方法，不会的朋友可以学习下2013-07-07
这篇文章主要介绍了mysql 一次更新(update)多条记录的思路,需要的朋友可以参考下2014-06-06
这篇文章主要介绍了MYSQL实现连续签到功能断签一天从头开始，非常不错，具有参考借鉴价值,需要的朋友可以参考下2017-05-05
在本篇文章里小编给大家整理的是一篇关于mysql并发控制原理知识点内容，需要的朋友们参考下吧。2020-02-02
最新评论