为什么相同的mysql sql在5.6和5.7之间有两个关于icp的结果

桌子

sql

5.6结果

5.7结果

---

首先，更新版本的数据库产品可能会为查询计划创建不同的输出，这不仅是意料之中的事，而且也是您想要的：您想要显示改进

现在：查询计划的要点是100%相同的：5.6中存在的所有列在5.7中显示相同-因此查询计划本身没有改变

改变的是，较新的版本显示了另外两列-因为在5.7中，对不同分区的并行查询的支持是新的，

partitions列

很容易解释

---

filtered

列源于查询计划器中的优化：显然，条件的选择性对于查询计划非常重要，而且在查询运行之前，显然不知道确切的选择性，但是newerquery planner会通知您它使用的是哪种Guestimate。这是一件好事。

谢谢，但我想知道为什么“额外”不同。第二个结果是否使用icp优化？“使用索引条件”是冗余的-

key=fnln

和

ref=const，const

已经包含此信息，因此它只是一个文本清理。我想这是因为PQ功能附带了很多可能的“额外”信息。当我运行不同的sql

explain select*from employees，其中first_name='Anneke'和last_name（如5.7中的'%Porenta%'）

时，额外的列当然会显示“Using index condition”！在这种情况下，第二个条件不是次饱和的，因为它不是一个完美的匹配，而是一个范围。@EugenRieck-即使在8.0中也没有并行查询。分区列列出了“分区修剪”的结果。该列存在于5.6中，但您必须要求它。建议您允许使用更长的名称。获取

EXPLAIN FORMAT=JSON选择…

以获得更多细节信息。对于这个简单的测试用例，8.0也缺少“使用索引条件”；我在其他案例中也看到过。

CREATE TABLE `employees` (
  `emp_no` int(11) NOT NULL,
  `birth_date` date NOT NULL,
  `first_name` varchar(14) NOT NULL,
  `last_name` varchar(16) NOT NULL,
  `gender` enum('M','F') NOT NULL,
  `hire_date` date NOT NULL,
  PRIMARY KEY (`emp_no`),
  KEY `fnln` (`first_name`,`last_name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

explain select * from employees where first_name='Anneke' and last_name='Porenta';