MySQL：浅析 Impossible WHERE noticed after reading const tables

使用 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 描述。