MySQL 8.0 实现了Index skip scan,翻译过来就是索引跳跃扫描。熟悉ORACLE的朋友是否是发现愈来愈像ORACLE了?再者,熟悉MySQL 5.7 的朋友是否是以为这个很相似当时优化器的选项MRR?好了,先具体说下什么 ISS,我后面所有用 ISS 简称。ide
*考虑如下的场景:优化
表t1有一个联合索引idx_u1(rank1,rank2),可是查询的时候却没有rank1这列,只有rank2。好比,select * from t1 where rank2 = 30。spa
那之前遇到这样的状况,若是没有针对rank2这列单独创建普通索引,这条SQL怎么着都是走的FULL TABLE SCAN。翻译
ISS 就是在这样的场景下产生的。ISS 能够在查询过滤组合索引不包括最左列的状况下,走索引扫描,而没必要要单独创建额外的索引。由于毕竟额外的索引对写开销很大,能省则省。3d
仍是拿刚才的例子来说,假设:blog
表t1的两个字段rank1,rank2。有这样的记录,索引
rank1, rank21 1001 2001 3001 4001 5001 6001 7005 1005 2005 3005 4005 500
咱们给出的SQL是,
图片
select * from t1 where rank2 >400,
那MySQL经过ISS把这条SQL变为,
ip
select * from t1 where rank1=1 and rank2 > 400union allselect * from t1 where rank1 = 5 and rank2 > 400;
能够看出来,MySQL其实内部本身把左边的列作了一次DISTINCT,完了加进去。ci
咱们拿实际的例子来看下。假设:
仍是刚才描述那张表,rank1字段值的distinct值比较少。查询计划的对比,
关闭 ISS,
很显然,ISS 扫描的行数要比以前的少不少。
ISS其实刚好适合在这种左边字段的惟一值较少的状况下,效率来的高。好比性别,状态等等。
那假设:rank1字段的distinct值比较多呢?
咱们从新造了点数据,此次,rank1的惟一值个数有快上万个。
咱们来再次看一遍这样SQL的执行计划,
此次咱们发现,不管如何MySQL也不会选择 ISS,而选了FULL INDEX SCAN。
那这样的场景就必须给rank2加一个单独索引了。
那来总结下 ISS 就是一句话:ISS 其实就是MySQL 8.0推出的适合联合索引左边列惟一值较少的状况的一种优化策略。