联合索引失效原理

本文详细介绍了数据库中B+树的结构及其在单值索引和联合索引中的应用,并通过实例分析了最佳左前缀原则、范围查询右边失效及like查询索引失效的原因。

参考
https://cloud.tencent.com/developer/article/1704743

1、单值索引B+树图

单值索引在B+树的结构里,一个节点只存一个键值对
在这里插入图片描述

2、联合索引

开局一张图,由数据库的a字段和b字段组成一个联合索引。
在这里插入图片描述
从本质上来说,联合索引也是一个B+树,和单值索引不同的是,联合索引的键值对不是1,而是大于1个。

a, b 排序分析
a顺序:1,1,2,2,3,3

b顺序:1,2,1,4,1,2

大家可以发现a字段是有序排列,b字段是无序排列(因为B+树只能选一个字段来构建有序的树)

一不小心又会发现,在a相等的情况下,b字段是有序的。

大家想想平时编程中我们要对两个字段排序,是不是先按照第一个字段排序,如果第一个字段出现相等的情况,就用第二个字段排序。这个排序方式同样被用到了B+树里。

3、联合索引分析

3.1 分析最佳左前缀原理

先举一个遵循最佳左前缀法则的例子

select * from testTable where a=1 and b=2

分析如下:

首先a字段在B+树上是有序的,所以我们可以通过二分查找法来定位到a=1的位置。

其次在a确定的情况下,b是相对有序的,因为有序,所以同样可以通过二分查找法找到b=2的位置。

再来看看不遵循最佳左前缀的例子

select * from testTable where b=2

分析如下:

我们来回想一下b有顺序的前提:在a确定的情况下。

现在你的a都飞了,那b肯定是不能确定顺序的,在一个无序的B+树上是无法用二分查找来定位到b字段的。

所以这个时候,是用不上索引的。大家懂了吗?

3.2 范围查询右边失效原理

举例

select * from testTable where a>1 and b=2

分析如下:

首先a字段在B+树上是有序的,所以可以用二分查找法定位到1然后将所有大于1的数据取出来a可以用到索引

b有序的前提是a是确定的值,那么现在a的值是取大于1的,可能有10个大于1的a,也可能有一百个a。

大于1的a那部分的B+树里,b字段是无序的(开局一张图),所以b不能在无序的B+树里用二分查找来查询,b用不到索引。

3.3 like索引失效原理
where name like "a%"

where name like "%a%"

where name like "%a"

我们先来了解一下%的用途

  • %放在右边,代表查询以"a"开头的数据,如:abc
  • 两个%%,代表查询数据中包含"a"的数据,如:cab、cba、abc
  • %放在左边,代表查询以"a"为结尾的数据,如cba

为什么%放在右边有时候能用到索引

  • %放右边叫做:前缀
  • %%叫做:中缀
  • %放在左边叫做:后缀

没错,这里依然是最佳左前缀法则这个概念
在这里插入图片描述
大家可以看到,上面的B+树是由字符串组成的。

字符串的排序方式: 先按照第一个字母排序,如果第一个字母相同,就按照第二个字母排序。。。以此类推

开始分析

一、%号放右边(前缀)

由于B+树的索引顺序,是按照首字母的大小进行排序,前缀匹配又是匹配首字母。所以可以在B+树上进行有序的查找,查找首字母符合要求的数据。所以有些时候可以用到索引。

二、%号放左边

是匹配字符串尾部的数据,我们上面说了排序规则,尾部的字母是没有顺序的,所以不能按照索引顺序查询,就用不到索引。

三、两个%%号

这个是查询任意位置的字母满足条件即可,只有首字母是进行索引排序的,其他位置的字母都是相对无序的,所以查找任意位置的字母是用不上索引的。

MySQL索引失效是数据库查询性能优化中一个关键问题,其背后的原因和机制与索引结构、查询优化器行为以及 SQL 语句的编写方式密切相关。 ### 索引失效的原因 1. **联合索引不满足最左匹配原则** MySQL 的联合索引(复合索引)依赖于最左前缀原则,即查询条件必须从索引的最左列开始,否则索引无法被使用。例如,对于联合索引 `(a, b, c)`,查询条件 `WHERE b = 2 AND c = 3` 将不会使用该索引,因为未包含最左列 `a` [^2]。 2. **模糊查询以通配符开头** 如果使用 `LIKE '%value'` 或 `LIKE '%value%'` 这样的模糊查询,由于无法确定前缀,MySQL 无法通过 B+ 树快速定位数据,导致索引失效。 3. **索引列参与运算或函数操作** 在索引列上进行任何运算(如 `WHERE id + 1 = 5`)或使用函数(如 `WHERE DATE(create_time) = '2023-01-01'`)都会破坏索引的有序性,使优化器无法利用索引进行查找 [^3]。 4. **类型转换** 当查询条件中的数据类型与索引列的数据类型不一致时,MySQL 会自动进行隐式类型转换,这会导致索引失效。例如,对 `VARCHAR` 类型的字段使用数字进行比较时,可能会触发类型转换 [^2]。 5. **使用 `OR` 条件不当** 如果 `OR` 条件中的一部分列没有索引,或者优化器认为使用索引效率不如全表扫描,那么整个查询可能不会使用索引。只有当 `OR` 两侧的列都有独立索引且优化器选择使用它们时,索引才会生效 [^4]。 6. **使用 `IS NOT NULL` 查询** 对于某些存储引擎和索引类型,`IS NOT NULL` 查询可能无法有效利用索引,尤其是在索引列允许 `NULL` 值的情况下 。 ### 索引失效的工作原理 MySQL 的索引基于 B+ 树结构,具有高度有序的特性,适用于等值查找和范围查找。当查询语句中出现上述索引失效条件时,优化器无法通过 B+ 树直接定位数据页,从而导致索引失效,转而使用全表扫描。 例如,在联合索引 `(a, b, c)` 的情况下,查询 `WHERE a = 1 AND c = 3` 可以使用索引,因为最左列 `a` 被使用,但 `b` 列缺失,导致只能使用到索引的第一列 `a`,而 `c` 列无法继续利用索引进行查找 。 ### 如何排查索引失效 1. 使用 `EXPLAIN` 命令分析查询执行计划,查看 `key` 字段是否为 `NULL`,表示未使用索引。 2. 检查查询语句是否包含对索引列的函数操作、类型转换或运算。 3. 确认查询是否符合最左匹配原则。 4. 分析表的统计信息是否准确,使用 `ANALYZE TABLE` 更新索引统计信息,帮助优化器做出更优决策 [^1]。 ### 示例代码:使用 EXPLAIN 分析索引使用情况 ```sql EXPLAIN SELECT * FROM t_user WHERE name = 'test'; ``` 该语句将输出查询的执行计划,通过查看 `key` 字段可以判断是否使用了索引。 ---
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值