脚本之家 服务器常用软件
快捷导航
您的位置：首页 → 数据库 → Mysql → MySQL索引失效

MySQL索引失效的典型案例

 更新时间：2021年06月05日 10:37:37   作者：DBA随笔  
索引在我们使用MySQL数据库时可以极大的提高查询效率，然而，有时候因为使用上的一些瑕疵就会导致索引的失效，无法达到我们使用索引的预期效果，今天介绍一种MySQL中几种常见的索引失效的原因，可以在以后的工作中尽可能避免因索引失效带来的坑。

典型案例

有两张表，表结构如下：

CREATE TABLE `student_info` (
  `id` int(11) NOT NULL,
  `name` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

CREATE TABLE `student_score` (
  `id` int(11) NOT NULL,
  `name` varchar(10) DEFAULT NULL,
  `score` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

其中一张是info表，一张是score表，其中score表比info表多了一列score字段。

插入数据：

mysql> insert into student_info values (1,'zhangsan'),(2,'lisi'),(3,'wangwu'),(4,'zhaoliu');
Query OK, 4 rows affected (0.01 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> insert into student_score values (1,'zhangsan',60),(2,'lisi',70),(3,'wangwu',80),(4,'zhaoliu',90);
Query OK, 4 rows affected (0.01 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> select * from student_info;
+----+----------+
| id | name     |
+----+----------+
|  2 | lisi     |
|  3 | wangwu   |
|  1 | zhangsan |
|  4 | zhaoliu  |
+----+----------+
4 rows in set (0.00 sec)

mysql> select * from student_score ;
+----+----------+-------+
| id | name     | score |
+----+----------+-------+
|  1 | zhangsan |    60 |
|  2 | lisi     |    70 |
|  3 | wangwu   |    80 |
|  4 | zhaoliu  |    90 |
+----+----------+-------+
4 rows in set (0.00 sec)

当我们进行下面的语句时：

mysql> explain select B.* 
       from 
       student_info A,student_score B 
       where A.name=B.name and A.id=1;
+----+-------------+-------+------------+-------+------------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys    | key     | key_len | ref   | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+------------------+---------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | A     | NULL       | const | PRIMARY,idx_name | PRIMARY | 4       | const |    1 |   100.00 | NULL        |
|  1 | SIMPLE      | B     | NULL       | ALL   | NULL             | NULL    | NULL    | NULL  |    4 |   100.00 | Using where |
+----+-------------+-------+------------+-------+------------------+---------+---------+-------+------+----------+-------------+
2 rows in set, 1 warning (0.00 sec)

为什么B.name上有索引，但是执行计划里面第二个select表B的时候，没有使用索引，而用的全表扫描？？？

解析：

该SQL会执行三个步骤：

1、先过滤A.id=1的记录，使用主键索引，只扫描1行LA

2、从LA这一行中找到name的值“zhangsan”，

3、根据LA.name的值在表B中进行查找，找到相同的值zhangsan，并返回。

其中，第三步可以简化为：

select * from student_score  where name=$LA.name

这里，因为LA是A表info中的内容，而info表的字符集是utf8mb4，而B表score表的字符集是utf8。

所以

在执行的时候相当于用一个utf8类型的左值和一个utf8mb4的右值进行比较，因为utf8mb4完全包含utf8类型(长字节包含短字节)，MySQL会将utf8转换成utf8mb4(不反向转换，主要是为了防止数据截断).

因此，相当于执行了：

select * from student_score  where CONVERT(name USING utf8mb4)=$LA.name

而我们知道，当索引字段一旦使用了隐式类型转换，那么索引就失效了，MySQL优化器将会使用全表扫描的方式来执行这个SQL。

要解决这个问题，可以有以下两种方法：

a、修改字符集。

b、修改SQL语句。

给出修改字符集的方法：

mysql> alter table student_score modify name varchar(10)  character set utf8mb4 ;
Query OK, 4 rows affected (0.03 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> explain select B.* from student_info A,student_score B where A.name=B.name and A.id=1;
+----+-------------+-------+------------+-------+------------------+----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys    | key      | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+------------------+----------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | A     | NULL       | const | PRIMARY,idx_name | PRIMARY  | 4       | const |    1 |   100.00 | NULL  |
|  1 | SIMPLE      | B     | NULL       | ref   | idx_name         | idx_name | 43      | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+------------------+----------+---------+-------+------+----------+-------+
2 rows in set, 1 warning (0.01 sec)

修改SQL的方法，大家可以自己尝试。

附：常见索引失效的情况

一、对列使用函数，该列的索引将不起作用。

二、对列进行运算(+，-，*，/，! 等)，该列的索引将不起作用。

三、某些情况下的LIKE操作，该列的索引将不起作用。

四、某些情况使用反向操作，该列的索引将不起作用。

五、在WHERE中使用OR时，有一个列没有索引，那么其它列的索引将不起作用。

六、隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误。

七、使用not in ,not exist等语句时。

八、当变量采用的是times变量，而表的字段采用的是date变量时.或相反情况。

九、当B-tree索引 is null不会失效,使用is not null时,会失效,位图索引 is null,is not null 都会失效。

十、联合索引 is not null 只要在建立的索引列（不分先后）都会失效。

以上就是MySQL索引失效的典型案例的详细内容，更多关于MySQL索引失效的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:

相关文章

  • MySQL8自增主键变化图文详解

    MySQL8自增主键变化图文详解

    众所周知MySQL 的主键可以是自增的,下面这篇文章主要给大家介绍了关于MySQL8自增主键变化的相关资料,文中通过示例代码介绍的非常详细,需要的朋友可以参考下
    2022-04-04
  • MySQL优化总结-查询总条数

    MySQL优化总结-查询总条数

    这篇文章主要介绍了MySQL优化总结-查询总条数的相关内容，文中进行简单的测试对比，具有一定参考价值，需要的朋友可以了解下。
    2017-10-10
  • Mysql 9.0.0创新MSI安装的实现

    Mysql 9.0.0创新MSI安装的实现

    本文提供了MySQL 9.0.0版本的MSI安装方法,包括安装前的下载链接,安装过程中的选项介绍,以及安装完成后的配置指南,具有一定的参考价值,感兴趣的可以了解一下
    2024-10-10
  • navicat连接mysql报错10060的解决办法

    navicat连接mysql报错10060的解决办法

    最近在学习中遇到了个小问题,现在将解决的办法分享给同样遇到这个问题的同学,这篇文章主要给大家介绍了关于navicat连接mysql报错10060的解决办法,需要的朋友可以参考下
    2023-03-03
  • Ubuntu20下MySQL 8.0.28 安装卸载方法图文教程

    Ubuntu20下MySQL 8.0.28 安装卸载方法图文教程

    这篇文章主要为大家详细介绍了Ubuntu20下MySQL 8.0.28 安装卸载方法图文教程，文中安装步骤介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
    2022-04-04
  • MySql主从复制实现原理及配置

    MySql主从复制实现原理及配置

    这篇文章主要介绍了MySql主从复制实现原理及配置,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
    2020-11-11
  • MySQL索引失效的几种情况汇总

    MySQL索引失效的几种情况汇总

    这篇文章主要介绍了MySQL索引失效的几种情况，帮助大家更好的理解和使用MySQL索引，感兴趣的朋友可以了解下
    2020-09-09
  • mysql 实现迁移数据库到另一台服务器

    mysql 实现迁移数据库到另一台服务器

    这篇文章主要介绍了mysql 实现迁移数据库到另一台服务器中，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
    2022-09-09
  • MySQL高级篇之索引的数据结构详解

    MySQL高级篇之索引的数据结构详解

    在MySQL中索引属于存储引擎级别的概念,不同存储引擎对索引的实现方式是不同的,下面这篇文章主要给大家介绍了关于MySQL高级篇之索引数据结构的相关资料,需要的朋友可以参考下
    2022-05-05
  • mysql下mysql-udf-http效率测试小记

    mysql下mysql-udf-http效率测试小记

    看到张宴的博客上关于"http/rest客户端的文章"，怎样安装啥的直接都跳过，下面直接进入测试阶段。
    2011-08-08

最新评论