使用 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');

然后执行如下查询语句:

EXPLAIN
select a.*, b.*
from class a, student b
where 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 的一个优化策略。

  • 当查询条件中包含了某个表的主键或者非空的唯一索引列
  • 该列的判定条件为等值条件
  • 目标值的类型与该列的类型一致
  • 目标值为一个确定的常量
EXPLAIN
select a.*, b.*
from class a, student b
where 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 描述。

Logo

更多推荐