你不得不知的MYSQL优化——索引下推

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
RDS AI 助手,专业版
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
简介: 你不得不知的MYSQL优化——索引下推

前言


说到MySQL的优化手段,不得不提的是MYSQL5.6中引入的一种新特性,索引下推,英文是 index condition pushdown,一般简称为 ICP。这也是MySQL面试中经常被问到的一个考点,本文就此分享下索引下推是怎么一回事,它是如何对提高查询效率起到帮助的。


理解索引下推


索引下推就是指在索引遍历过程中,对索引中包含的字段先做判断,直接过滤掉不满足条件的记录,减少回表次数来提高查询效率。

如何理解呢? 我们直接上栗子来解释:

  1. 新建用户表
CREATE TABLE user(
     `id` int NOT NULL AUTO_INCREMENT,
     `zipcode` varchar(20) DEFAULT NULL,
     `name` varchar(20) DEFAULT NULL,
     `address` varchar(50) DEFAULT NULL,
     PRIMARY KEY (`id`),
     index idx_zip_name(`zipcode`, `name`)
) ENGINE=INNODB;
insert into user(zipcode, name, address)
values ('100001', '陈旭阳', '杭州'),
       ('100001', '胡歌', '上海'),
       ('200002', '杨幂', '北京'),
       ('300002', '刘诗诗', '南京');
  • 创建了基于邮编zipcode和名称name的联合索引idx_zip_name,用于查找某个邮编下,名字包含陈的人。
  1. 查询语句
select * from user where zipcode = '100001' and name like '%陈%' and address like '%余杭%';
  • 查询条件根据zipcode精确查找,nameaddress全模糊匹配。

如果MySQL5.6以前, 没有索引下推特性,整个流程如下图:

1671199612586.jpg

  • 联合索引中知道100001的数据项,因为name是全模糊,无法走索引,address压根没有索引,他们无法在联合索引中过滤,怎么办?只能回到数据最全的聚簇索引上进行name like '%陈%' and address like '%余杭%'这个逻辑的过滤。
  • 按照上面的方式,每次回到聚簇索引这个一个称做 “回表” 的过程,势必增加磁盘IO,从而影响查询性能。

那么有什么办法可以优化呢?

优化的目标就是尽量减少回表这一过程,我们发现联合索引上竟然有了name字段的信息,为什么我们不能充分利用呢? name like '%陈%'我们可以直接在索引树上进行判断name是不是包含陈,从而减少回表次数。这也正是MySQL5.6中优化的特性,如下图所示:


1671199621200.jpg


  • 根据查询条件name like '%陈%'陈旭阳包含了陈, 那么它去回表过滤address内容。
  • 而其他记录比如胡歌等不包含陈,那么其他记录就无需回表,再次去匹配address地址是否符合了,相当于减少了回表。

上面图中的索引都用表格表示,只是为了方便,实际上索引底层数据结构是B+数据,如果不了解的,可以阅读文章:一步步带你设计MySQL索引数据结构

一句话总结:索引下推(index condition pushdown,ICP),有效的减少了回表次数,提高了查询效率。


索引下推性能比较


竟然索引下推可以提高效率,那我们验证下。

  1. 沿用上面的user表
  2. 创建存储过程,添加数据
DELIMITER //
CREATE PROCEDURE insert_user(max_num INT)
BEGIN
DECLARE i INT DEFAULT 0;
    SET autocommit = 0;
    REPEAT
    SET i = i + 1;
    INSERT INTO user(zipcode,name,address) VALUES ('10018', '陈旭阳', '杭州');
    UNTIL i =max_num
END REPEAT;
COMMIT;
END //
DELIMITER ;
  1. 调用存储过程
call insert_user(1000000);
  1. 打开性能检查工具profiling
set profiling = 1;
  1. 启用索引下推方式查询
select * from user where zipcode = '10018' and name like '%李%';
  1. 禁用索引下推方式查询
select /*+ no_icp(user) */ * from user where zipcode = '10018' and name like '%李%';
  1. 查看当前会话下的profiles
show profiles;
  1. 结果如下:
  • 有索引下推0.21s

1671199652003.jpg

  • 没有索引下推花了2.6s

1671199666001.jpg

使用ICP性能提高还是比较明显的,特别是数据量大的情况下。


执行计划中的索引下推


如何判断你的SQL中是否使用了到索引下推的特性呢?

我们利用explain查看SQL的执行计划时,如果发现Extra字段中有Using index condition,即表示使用到了索引下推。

1671199685457.jpg

注意如果发现一直没有用上索引下推,需要检查下功能是否被禁用,默认是打开的。

  • 可以通过设置系统变量optimizer_switch控制:index_condition_pushdown
# 打开索引下推
SET optimizer_switch = 'index_condition_pushdown=on';
# 关闭索引下推
SET optimizer_switch = 'index_condition_pushdown=off';


总结


本文介绍了索引下推特性,并简要分析了它的实现原理。虽然说,这个特性MySQL支持了,但是为什么我们还要学习理解它呢,因为它对于我们如何写SQL、如何创建索引还是起着指导作用的。如果本文对你有帮助的话,请留下一个赞吧。

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
目录
相关文章
|
7月前
|
存储 SQL 关系型数据库
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
|
7月前
|
存储 关系型数据库 MySQL
MySQL数据库索引的数据结构?
MySQL中默认使用B+tree索引,它是一种多路平衡搜索树,具有树高较低、检索速度快的特点。所有数据存储在叶子节点,非叶子节点仅作索引,且叶子节点形成双向链表,便于区间查询。
222 4
|
9月前
|
存储 关系型数据库 MySQL
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
|
8月前
|
SQL 缓存 关系型数据库
MySQL 慢查询是怎样优化的
本文深入解析了MySQL查询速度变慢的原因及优化策略,涵盖查询缓存、执行流程、SQL优化、执行计划分析(如EXPLAIN)、查询状态查看等内容,帮助开发者快速定位并解决慢查询问题。
350 0
|
6月前
|
缓存 关系型数据库 MySQL
降低MySQL高CPU使用率的优化策略。
通过上述方法不断地迭代改进,在实际操作中需要根据具体场景做出相对合理判断。每一步改进都需谨慎评估其变动可能导致其他方面问题,在做任何变动前建议先在测试环境验证其效果后再部署到生产环境中去。
280 6
|
7月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分,阐述了 char 与 varchar 在存储方式和性能上的差异,以及事务的 ACID 特性、并发事务问题及对应的隔离级别(MySQL 默认 REPEATABLE READ)。 索引基础部分,详解了 InnoDB 默认的 B+tree 索引结构(多路平衡树、叶子节点存数据、双向链表支持区间查询),区分了聚簇索引(数据与索引共存,唯一)和二级索引(数据与索引分离,多个),解释了回表查询的概念及优化方法,并分析了 B+tree 作为索引结构的优势(树高低、效率稳、支持区间查询)。 索引优化部分,列出了索引创建的六大原则
181 2
|
8月前
|
存储 关系型数据库 MySQL
MySQL覆盖索引解释
总之,覆盖索引就像是图书馆中那些使得搜索变得极为迅速和简单的工具,一旦正确使用,就会让你的数据库查询飞快而轻便。让数据检索就像是读者在图书目录中以最快速度找到所需信息一样简便。这样的效率和速度,让覆盖索引成为数据库优化师傅们手中的尚方宝剑,既能够提升性能,又能够保持系统的整洁高效。
251 9
|
7月前
|
存储 SQL 关系型数据库
MySQL 动态分区管理:自动化与优化实践
本文介绍了如何利用 MySQL 的存储过程与事件调度器实现动态分区管理,自动化应对数据增长,提升查询性能与数据管理效率,并详细解析了分区创建、冲突避免及实际应用中的关键注意事项。
330 0
|
9月前
|
机器学习/深度学习 关系型数据库 MySQL
对比MySQL全文索引与常规索引的互异性
现在,你或许明白了这两种索引的差异,但任何技术决策都不应仅仅基于理论之上。你可以创建你的数据库实验环境,尝试不同类型的索引,看看它们如何影响性能,感受它们真实的力量。只有这样,你才能熟悉它们,掌握什么时候使用全文索引,什么时候使用常规索引,以适应复杂多变的业务需求。
240 12
|
5月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
444 158

推荐镜像

更多