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