联合索引与索引下推

本文详细解释了联合索引的工作原理,包括最左匹配规则,以及如何利用索引覆盖和索引下推来提升查询性能。重点讨论了何时选择合适的联合索引并给出了生产环境中的应用实例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、联合索引

联合索引大家都知道,就不介绍了。

二、最左匹配原则

  在通过联合索引检索数据时,从索引中最左边的列开始,一直向右匹配,如果遇到范围查询(>、<、between、like等),就停止后边的匹配。

这个定义不太好理解,我解释一下:
假如对字段 (a, b, c) 建立联合索引,现在有这样一条查询语句:

where a > xxx and b=yyy and c=zzz
where a like 'xxx%' and b=yyy and c=zzz

  在这个条件语句中,只有a用到了索引,后面的b,c就不会用到索引。这就是“如果遇到范围查询(>、<、between、like等),就停止后边的匹配。”的意思。

还是假如对字段 (a, b, c) 建立联合索引,

2.1 如下查询语句可以使用到索引:

where a = xxx
where a = xxx and b = xxx
where a = xxx and b = xxx and c = xxx
where a like 'xxx%'
where a > xxx
where a = xxx order by b
where a = xxx and b = xxx order by c
group by a

2.1 如下查询条件也会使用索引:

where b = xxx and a = xxx
where a = xxx and c = xxx and b = xxx

虽然b和a的顺序换了,但是mysql中的优化器会帮助我们调整顺序。

2.3 如下查询条件只用到联合索引的一部分:

where a = xxx and c = xxx   可以用到 a 列的索引,用不到 c 列索引。
 
where a like 'xxx%' and b = xxx 可以用到 a 列的索引,用不到 b 列的索引。
 
where a > xxx and b = xxx 可以用到 a 列的索引,用不到 b 列的索引。

2.4 如下查询条件完全用不到索引

where b = xxx
where c = xxx
where a like '%xxx'			-- 不满足最左前缀
where d = xxx order by a	-- 出现非排序使用到的索引列 d 
where a + 1 = xxx	-- 使用函数、运算表达式及类型隐式转换等

2.5 如何选择合适的联合索引

  1. where a = xxx and b = xxx and c = xxx 如果我们的查询是这样的,建索引时,就可以考虑将选择性高的列放在索引的最前列,选择性低的放后边;
  2. 如果是 where a > xxx and b = xxx 或 where a like ‘xxx%’ and b = xxx 这样的语句,可以对 (b, a) 建立索引;
  3. 如果是 where a = xxx order by b 这样的语句,可以对 (a, b) 建立索引;

三、索引覆盖

建立了联合索引后,直接在索引中就可以得到查询结果,从而不需要回表查询聚簇索引中的行数据信息。

索引覆盖可以带来很多的好处:

  1. 辅助索引不包含行数据的所有信息,故其大小远小于聚簇索引,因此可以减少大量的IO操作;
  2. 索引覆盖只需要扫描一次索引树,不需要回表扫描聚簇索引树,所以性能比回表查询要高;
  3. 索引中列值是按顺序存储的,索引覆盖能避免范围查询回表带来的大量随机IO操作。

explain语句中,entra列如果是Using index,就表示使用到了索引 , 并且所取的数据完全在索引中就能拿到,也就是用到了索引覆盖

四、索引下推

索引下推是索引下推是 MySQL 5.6 及以上版本上推出的,用于对查询进行优化。

索引下推把本应该在 server 层进行筛选的条件,下推到存储引擎层来进行筛选判断,这样能有效减少回表

举例说明:
首先使用联合索引(name,age),现在有这样一个查询语句:
select * from t_user where name like ‘L%’ and age = 17;

这条语句从最左匹配原则上来说是不符合的,原因在于只有name用的索引,但是age并没有用到。

不用索引下推的执行过程:

  • 第一步:利用索引找出name带’L’的数据行:LiLei、Lili、Lisa、Lucy 这四条索引数据;
  • 第二步:再根据这四条索引数据中的 id 值,逐一进行回表扫描,从聚簇索引中找到相应的行数据,将找到的行数据返回给 server 层;
  • 第三步:在server层判断age = 17,进行筛选,最终只留下 Lucy 用户的数据信息。

使用索引下推的执行过程:

  • 第一步:利用索引找出name带’L’的数据行:LiLei、Lili、Lisa、Lucy 这四条索引数据;
  • 第二步:根据 age = 17 这个条件,对四条索引数据进行判断筛选,最终只留下 Lucy 用户的数据信息
    (注意:这一步不是直接进行回表操作,而是根据 age = 17 这个条件,对四条索引数据进行判断筛选);
  • 第三步:将符合条件的索引对应的 id 进行回表扫描,最终将找到的行数据返回给 server 层。

比较二者的第二步我们发现,索引下推的方式极大的减少了回表次数。

索引下推需要注意的情况:
下推的前提是索引中有 age 列信息,如果是其它条件,如 gender = 0,这个即使下推下来也没用。

开启索引下推:

索引下推是 MySQL 5.6 及以上版本上推出的,用于对查询进行优化。默认情况下,索引下推处于启用状态。我们可以使用如下命令来开启或关闭:

set optimizer_switch='index_condition_pushdown=off';  -- 关闭索引下推
set optimizer_switch='index_condition_pushdown=on';  -- 开启索引下推

配置文件:

[mysqld]
optimizer_switch="index_condition_pushdown=on"-- 开启索引下推
optimizer_switch="index_condition_pushdown=off" -- 关闭索引下推

查询:

SELECT @@optimizer_switch;

五、生产中例子(脱敏,用abc代替)

假如对字段 (a, b, c) 建立联合索引,现在有这样一条查询语句:

where a='xx' and c='yy';

目前索引:索引a;——发现查询慢;
接着,索引:a,改为联合索引:abc;

按理说where条件用了ac,效率不应该很高,但事实上,效率提高了。为什么呢?
——其实这就是索引下推;

文章引用:
索引知识二:联合索引、覆盖索引和索引下推详解

### MySQL 索引下推的工作原理 索引下推(Index Condition Pushdown, ICP)是一种从 MySQL 5.6 版本开始引入的性能优化技术,其主要作用是减少存储引擎层服务器层之间的交互次数,从而降低查询过程中回表操作的数量[^3]。 #### 原理概述 在传统的查询执行流程中,MySQL 的存储引擎会先根据索引定位到可能符合条件的记录范围,然后将这些记录返回给服务器层进行进一步过滤。然而,这种方式可能会导致大量不必要的数据被传输至服务器层处理。而通过启用 ICP 功能,部分原本由服务器层完成的条件筛选工作可以转移到存储引擎层面实现。这意味着,在读取索引条目的同时即可应用某些查询条件来排除不匹配的行,进而显著减少需要访问的实际数据量[^4]。 例如,在一个复合查询条件下,如果存在多个列上的限制表达式,则可以通过仅扫描那些初步满足索引定义范围内约束的部分来进行更早阶段的选择性裁剪[^2]。 ```sql SELECT * FROM customers WHERE age >= 18 AND address LIKE '%Francisco%'; ``` 在这个例子当中,假设 `age` 字段已经建立了相应的索引结构;那么借助于索引下推机制的作用之下,不仅能够依据该字段迅速缩小目标集合规模,而且还能同步考虑其他非键属性如地址字符串模式匹配这样的复杂逻辑运算规则,以此达到双重削减候选集的效果。 ### 实现方式 具体来说,MySQL 是如何做到这一点呢?实际上就是把原来属于 SQL 层面负责解析并判断是否符合最终结果集标准的一部分计算任务下沉到了更低层次即 InnoDB 存储引擎内部去执行: - 当某个特定类型的次级索引被用于辅助检索过程时; - 如果发现除了主键之外还有额外附加的信息可用于加速决策制定的话, 此时就会激活所谓的“index condition push down”行为模式——允许直接利用这些附加信息来做预筛选动作而不是简单地依赖原始物理页加载后再做二次验证。 这种做法的好处显而易见:一方面它可以有效避免过多无关紧要的数据进入内存缓冲池占用宝贵资源;另一方面也能加快整个请求响应速度因为减少了磁盘I/O次数以及CPU周期消耗等问题的发生几率。 ### 应用场景分析 考虑到上述特点之后我们可以总结出几个比较典型的适合采用索引下推策略的应用场合如下所示: 1. **多列联合索引** - 对于涉及两个或者更多不同维度限定语句组成的复杂查询而言尤为适用; ```sql SELECT * FROM orders WHERE customer_id = 100 AND product_id > 50 ORDER BY order_date DESC LIMIT 10; ``` 此处假定 `(customer_id, product_id)` 组成了一个多维组合型二级索引对象的情况下,就可以充分利用ICP特性使得只针对那些既符合客户编号又大于指定商品ID阈值的有效项目展开深入探讨研究活动去了. 2. **全文搜索引擎集成环境下的模糊查找支持** 类似之前提到过的邮政编码样式的地理区域名称搜索实例同样非常契合此类需求特征描述要求: ```sql SELECT COUNT(*) AS num_users FROM users USE INDEX (idx_age) WHERE age BETWEEN 20 AND 30 AND city REGEXP '^New.*York$'; ``` 这里强调的是即使面对较为棘手复杂的正则表达式匹配任务也同样有机会享受到来自底层硬件设施所提供的强大助力效果哦! ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值