我们兴致勃勃地建了一张InnoDB表,想测试一下索引的性能,对表中的聚簇索引肆意妄为,对id执行各种查询,玩得不亦乐乎。 这时候,你突发奇想,在表上建了个二级索引,执行了一下查询,发现Extra列里面出现了你从未见过、书上也没讲到的Usin
我们兴致勃勃地建了一张InnoDB表,想测试一下索引的性能,对表中的聚簇索引肆意妄为,对id执行各种查询,玩得不亦乐乎。
这时候,你突发奇想,在表上建了个二级索引,执行了一下查询,发现Extra列里面出现了你从未见过、书上也没讲到的Using index condition。
你慌了,到网上找答案,找到的都是类似这样的东西:
你明白了,可是当你写了一个索引字段的范围查询后,面对着Extra中再次出现的Using index condition,又一次陷入了沉思······
其实,这个问题就是Mysql的版本问题,老版本中没有使用这样的优化算法,所以在老板本书上都很难发现。
Using index condition的出现,意味着mysql在执行这条语句时使用了Index Condition Pushdown Optimization(ICP),我愿意称之为”索引条件下压优化“。
这个优化的具体操作是这样的:
(先放一张Mysql层次图便于后面理解)
ICP用于当MySQL想要使用索引并且需要遍历表中的所有行的时候。如果没有ICP,存储引擎就会遍历通过索引锁定的行,并把这些行从表中返回到服务端,在服务端进行where条件的应用。
如果可以使用ICP,如果where条件可以被用于索引中存储的列,那么服务端就会将这一部分where条件压入存储引擎。然后存储引擎会在索引列上针对where条件进行筛选,只有某个索引列的值满足了条件,那么它背后所代表的行才能被读取。由此可见,ICP可以减少存储引擎访问存储系统(大概率是I/O操作)的次数和服务端访问存储引擎的次数。
Using index condition的出现,也就是ICP的使用情况,有以下几点注意事项:
为了更好地理解这个优化是如何工作的,我们先来看没有ICP的where查询中,索引扫描是如何进行的:
如果使用ICP的话,这个流程将变为:
举个栗子:
假设有一个表包含了一个人的住址信息,然后在其上建立了一个索引:
INDEX ( zipcode , lastname , firstname )
然后我们执行以下查询:
SELECT * FROM people WHERE zipcode='95054' AND lastname LIKE '%etrunia%' AND address LIKE '%Main Street%';
小学二年级学过的知识告诉我们,这个查询没法用上我们的索引,因为lastname整了个通配符开头的LIKE,必须全表扫。
可是现在我们有ICP了,MySQL会在使用索引查找zipcode之后,检查这些索引列中是否满足last name LIKE "%etrunia%" ,而这个操作是在全表扫描之前的,也就是说,在这一步操作之后,我们就需要扫描满足条件的索引代表的行,不用进行全表扫描了,避免了我们读取满足zipcode条件,但是不满足lastname条件的行。
ICP默认使用,如果想要关闭或再打开,可以调用以下命令:
SET optimizer_switch = 'index_condition_pushdown=off';SET optimizer_switch = 'index_condition_pushdown=on';
(10205101490 数据库报告一部分 从官网上读取文档总结在此)
来源地址:https://blog.csdn.net/ezioetay/article/details/125031492
--结束END--
本文标题: Extra中出现的Using index condition到底什么意思?
本文链接: https://lsjlt.com/news/402047.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0