Mysql 数据库表中有索引或者查询慢问题分析

前言：

问题分析:

在进行数据库查询的时候，我们都知道索引可以加快数据查询的效力。但是在实际的业务场景下，常常会遇到即便在表中增加了索引，但是一样或者会出现数据查询慢的问题。这就需要具体分析数据查询慢的具体缘由究竟是甚么了。

首先需要进行确认的就是 SQL 语句中对应的条件查询中字段有无建立索引。虽然说表中已有索引，但是不一定 SQL 语句中的查询字段有建立索引，所以第一步应当进行 SQL 中的字段索引确认。如果没有建立对应的索引可以先尝试下建立索引再进行查询。如果已有了索引，查询的字段也是索引字段，那末就要斟酌下是不是是出现了索引失效的情况。下面我们再具体分析下，看看在哪些场景下会出现索引失效的情况。

索引失效场景：

在分析索引失效场景之前，我们一定要要清楚索引结构的特点是甚么。

我们再来看下 Mysql 数据库索引的结构特点：

本文以 user_info 这张表来作为分析的基础，在 user_info 这张表上，我们分别创建了 idx_name 和 idx_phone 二级索引和 idx_age_address 联合索引。

1、字段类型不匹配致使的索引失效

进行 SQL 数据查询的时候，where 条件字段类型与实际表中字段类型不匹配的时候，Mysql 会进行隐式的数据类型转换，而类型转换会使用到内置函数，致使在进行数据查询的时候并没有使用索引。我们可使用 explain 命令查看 sql 语句。可以看的出来在 key 栏中，对应的值为 null，说明并没有使用索引进行查询。

但是如果在依照 phone_number 字段为字符串类型进行查询的时候，Mysql 没有进行隐式的类型转换，所以终究或者走了索引。

2、被索引字段使用了表达式计算

在 where 中条件使用了条件表达式的时候，数据表中的索引就失效了，实际是由于 Mysql 需要将索引字段取出来以后再进行表达式的条件判断，因此进行了全表扫描，致使索引失效。

3、被索引字段使用了内置函数

索引字段实际上是依赖于全部 B+索引树的遍历，而索引树的遍历又依赖于索引树底层叶子节点的有序性。索引保存的是索引列的原始值，如果经过函数计算，Mysql 的解释器没法判断计算后的索引在原来的索引树上会不会可以被索引到，因此它就直接放弃使用索引查询了。

4、like 使用了 %X 模糊匹配

使用左模糊匹配和左右模糊匹配都会致使索引失效，但是使用右模糊匹配，或者可以走索引查询的。

由于 B+树依照索引值进行排序的，实际是依照最左前缀进行比较，而使用了 %作为最左前缀，Mysql 没法判断其有序性，因此只能进行全表扫描查询。

5、索引字段不是联合索引字段的最左字段

如果数据库表中有联合索引的话，我们在 SQL 查询语句中使用的索引字段又不是联合索引的最左字段，那末就会致使索引失效。

实际上在 Mysql 中的索引检索是遵守最左匹配原则的，同时 B+索引树的叶子节点的有序性也是建立在最左匹配原则之上，而上述的 4、5 两种情况实际违背了最左匹配原则，因此 Mysql 履行器则没法使用对应的索引进行检查查询。

6、or 分割的条件

如果 or 左侧的条件存在索引，而右侧的条件没有索引，不走索引
由于 OR 的含义就是两个只要满足一个便可，因此只有一个条件列进行了索引是没成心义的，只要有条件列没有进行索引，就会进行全表扫描，因此索引的条件列也会失效。

7、in、not in 可能会致使索引失效

这里需要说明的是使用 in 和 not in 走不走索引，实际和 Mysql 的版本和表中的数据量有关系，在 8.0 以后的版本是走索引的。

注：此处加了地址的索引。

总结

本文总结了几种索引失效的场景，希望在大家平时项目开发时遇到类似的问题可以有对应的问题排查方向。致使索引失效的场景归结起来实际就是在索引使用上面存在瑕疵终究致使了索引失效的情况，这就像我们小时候打拳皇 97 一样，遥感和按钮的组合如果姿式不对，就没办法放出我们希望的大招。总之需要一些经验的积累，同时在写完 SQL 的时候可以进行履行检查，避免在线上出现索引失效的问题。

到此这篇关于为何Mysql 数据库表中有索引或者查询慢的文章就介绍到这了,更多相关Mysql 查询慢原理内容请搜索之前的文章或继续浏览下面的相关文章希望大家以后多多支持！