本文共 1611 字，大约阅读时间需要 5 分钟。

使用 EXPLAIN 执行计划的时候，在 Extra 中偶尔会看到这样的描述：

Impossible WHERE noticed after reading const tables

字面上的意思是：读取const tables表之后， 没有发现匹配的行。  通过示例我们重现一下该场景。首先创建两张表，班级表（class），学生表（student）。

CREATE TABLE `class` (  `id` int(11) NOT NULL,  `name` varchar(100) DEFAULT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;INSERT INTO `class` VALUES ('1', '计算机1班');INSERT INTO `class` VALUES ('2', '计算机2班');INSERT INTO `class` VALUES ('3', '计算机3班');CREATE TABLE `student` (  `id` int(11) NOT NULL,  `name` varchar(100) DEFAULT NULL,  `class_id` int(11) DEFAULT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;INSERT INTO `student` VALUES ('1', '张三', '1');INSERT INTO `student` VALUES ('2', '李四', '2');INSERT INTO `student` VALUES ('3', '王五', '3');

然后执行如下查询语句：

EXPLAINselect a.*, b.*from class a, student bwhere b.id=99 and a.id = b.class_id

在 MySQL 5.6.22 下的执行结果如下图所示，符合我们的预期。 

而在 MySQL 5.7.17 下的执行结果如下图所示，可以发现同样的表结构、同样的数据、同样的查询语句，发现 Extra 中的显示的内容为“no matching row in const table”，这句话理解起来就容易多了。我估计之前的语句表达的语义不太明确，才在新的版本中进行的修改吧（个人猜测，勿喷哈）。 

产生“ Impossible WHERE noticed after reading const tables”的原因是这样的，当在查询语句中存在满足如下条件的 WHERE 语句时，MySQL在 EXPLAIN 之前会优先根据这一条件查找出对应的记录，并用记录的实际值替换查询中所有使用到的该表属性。这是因为满足以下四个条件时，就会使得针对该表的查询最多只能产生一条命中结果。在该表无法命中数据的情况下就会提示“在 const table 表中没有找到匹配的行”，而这个 “const table”就指的是满足下面四个条件的表。这是 MySQL 的一个优化策略。

当查询条件中包含了某个表的主键或者非空的唯一索引列

该列的判定条件为等值条件 目标值的类型与该列的类型一致 目标值为一个确定的常量

EXPLAINselect a.*, b.*from class a, student bwhere b.id=99 and a.id = b.class_id

上面的语句中，student （b）表刚好满足以上的4个条件，分析如下：

b.id 为表的主键

b.id=99 为等值条件 99 为 int 类型，id 也为 int 类型 99 是一个确定的常量 根据b.id=99的查询条件，无法命中数据。因此出现了我们期望的 Extra 描述。  

转载地址：https://blog.csdn.net/liao0801_123/article/details/84030615 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！