mysql索引失效的问题
一、查询条件包含or，可能导致索引失效
新建一个user表，它有一个普通索引userId，
结构如下：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` int(11) NOT NULL, `age` int(11) NOT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `idx_userId` (`userId`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
执行一条查询sql，它是会走索引的，
如下图所示：
把or条件+没有索引的age加上，并不会走索引，
如图：
分析&结论：
- 对于or+没有索引的age这种情况，假设它走了userId的索引，但是走到age查询条件时，它还得全表扫描，也就是需要三步过程： 全表扫描+索引扫描+合并
- 如果它一开始就走全表扫描，直接一遍扫描就完事。
- mysql是有优化器的，处于效率与成本，遇到or条件，索引可能失效，看起来也合情合理。
注意：如果or条件的列都加了索引，索引可能会走的，大家可以自己试一试。
二、如何字段类型是字符串
where时一定用引号括起来，否则索引失效
假设demo表结构如下：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` varchar(32) NOT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `idx_userId` (`userId`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
userId为字符串类型，是B+树的普通索引，如果查询条件传了一个数字过去，它是不走索引的，
如图所示：
如果给数字加上'',也就是传一个字符串呢，当然是走索引，
如下图：
分析与结论：
为什么第一条语句未加单引号就不走索引了呢？
这是因为不加单引号时，是字符串跟数字的比较，它们类型不匹配，MySQL会做隐式的类型转换，把它们转换为浮点数再做比较。
三、like通配符可能导致索引失效
并不是用了like通配符，索引一定失效，而是like查询是以%开头，才会导致索引失效。
表结构：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` varchar(32) NOT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `idx_userId` (`userId`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
like查询以%开头，索引失效，
如图：
把%放后面，发现索引还是正常走的，
如下：
把%加回来，改为只查索引的字段（覆盖索引），发现还是走索引，惊不惊喜，意不意外
结论：
like查询以%开头，会导致索引失效。可以有两种方式优化：
- 使用覆盖索引
- 把%放后面
附: 索引包含所有满足查询需要的数据的索引，称为覆盖索引(Covering Index)。
四、联合索引
查询时的条件列不是联合索引中的第一个列，索引失效。
表结构：（有一个联合索引 idx_userid_age ， userId 在前， age 在后）
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` int(11) NOT NULL, `age` int(11) DEFAULT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `idx_userid_age` (`userId`,`age`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
在联合索引中，查询条件满足最左匹配原则时，索引是正常生效的。
请看demo：
如果条件列不是联合索引中的第一个列，索引失效，
如下：
分析与结论：
- 当我们创建一个联合索引的时候，如(k1,k2,k3)，相当于创建了（k1）、(k1,k2)和(k1,k2,k3)三个索引，这就是最左匹配原则。
- 联合索引不满足最左原则，索引一般会失效，但是这个还跟Mysql优化器有关的。
五、在索引列上使用mysql的内置函数
索引失效。
表结构：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` varchar(32) NOT NULL, `loginTime` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_userId` (`userId`) USING BTREE, KEY `idx_login_time` (`loginTime`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
虽然loginTime加了索引，但是因为使用了mysql的内置函数Date_ADD()，索引直接GG，
如图：
六、对索引列运算（如，+、-、*、/）
索引失效。
表结构：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` varchar(32) NOT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_age` (`age`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
虽然age加了索引，但是因为它进行运算，索引直接迷路了。。。
如图：
七、索引字段上使用（！= 或者 < >，not in）
可能会导致索引失效。
表结构：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` int(11) NOT NULL, `age` int(11) DEFAULT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `idx_age` (`age`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
虽然age加了索引，但是使用了！= 或者 < >，not in这些时，索引如同虚设。
如下：
八、索引字段上使用is null， is not null
可能导致索引失效。
表结构：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `card` varchar(255) DEFAULT NULL, `name` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_name` (`name`) USING BTREE, KEY `idx_card` (`card`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
单个name字段加上索引，并查询name为非空的语句，其实会走索引的，
如下：
单个card字段加上索引，并查询name为非空的语句，其实会走索引的，
如下：
但是它两用or连接起来，索引就失效了，
如下：
九、左连接查询或者右连接查询查询关联的字段编码格式不一样
可能导致索引失效。
新建两个表，一个user，一个user_job
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) CHARACTER SET utf8mb4 DEFAULT NULL, `age` int(11) NOT NULL, PRIMARY KEY (`id`), KEY `idx_name` (`name`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
CREATE TABLE user_job ( id int(11) NOT NULL, userId int(11) NOT NULL, job varchar(255) DEFAULT NULL, name varchar(255) DEFAULT NULL, PRIMARY KEY (id), KEY idx_name (name) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
user 表的name字段编码是utf8mb4，而user_job表的name字段编码为utf8。
执行左外连接查询,user_job表还是走全表扫描，
如下：
如果把它们改为name字段编码一致，还是会走索引。
十、mysql估计使用全表扫描要比使用索引快
则不使用索引。
当表的索引被查询，会使用最好的索引，除非优化器使用全表扫描更有效。优化器优化成全表扫描取决与使用最好索引查出来的数据是否超过表的30%的数据。
不要给'性别'等增加索引。如果某个数据列里包含了均是"0/1"或“Y/N”等值，即包含着许多重复的值，就算为它建立了索引，索引效果不会太好，还可能导致全表扫描。
Mysql出于效率与成本考虑，估算全表扫描与使用索引，哪个执行快。这跟它的优化器有关，来看一下它的逻辑架构图吧（图片来源网上）
总结
总结了索引失效的十大杂症，在这里来个首尾呼应吧，分析一下我们生产的那条慢sql。
模拟的表结构与肇事sql如下：
CREATE TABLE `user_session` ( `user_id` varchar(32) CHARACTER SET utf8mb4 NOT NULL, `device_id` varchar(64) NOT NULL, `status` varchar(2) NOT NULL, `create_time` datetime NOT NULL, `update_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`user_id`,`device_id`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
explain update user_session set status =1 where (`user_id` = '1' and `device_id`!='2') or (`user_id` != '1' and `device_id`='2')
分析：
- 执行的sql，使用了
or条件，因为组合主键(user_id,device_id)，看起来像是每一列都加了索引，索引会生效。 - 但是出现
!=,可能导致索引失效。也就是or+!=两大综合症，导致了慢更新sql。
解决方案：
那么，怎么解决呢？我们是把 or 条件拆掉，分成两条执行。同时给 device_id 加一个普通索引。
最后，总结了索引失效的十大杂症，希望大家在工作学习中，参考这十大杂症，多点结合执行计划 expain 和场景，具体分析 ，而不是按部就班，墨守成规，认定哪个情景一定索引失效。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。
相关文章
DQL（Data Query Language 数据查询语言）：用于查询数据库对象中所包含的数据。DQL语言主要的语句：SELECT语句。DQL语言是数据库语言中最核心、最重要的语句，也是使用频率最高的语句2022-12-12
这篇文章主要给大家介绍了MySQL中联表更新与删除的语法,文中通过示例代码介绍的很详细，有需要的朋友可以参考借鉴，下面来跟着小编一起学习学习吧。2017-01-01
MySQL索引是加速数据检索的特殊结构,用于存储列值与位置信息,常见的索引类型包括：主键索引、唯一索引、普通索引、复合索引、全文索引和空间索引等,本文介绍MySQL索引简介及常见的索引类型有哪些,感兴趣的朋友一起看看吧2025-08-08
这篇文章主要介绍了MySQL判断列的值既不为NULL又不为空字符串的问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2023-08-08
这篇文章主要介绍了mysql单表查询及多表查询命令详解,本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下2023-07-07
在前面的文章中，白日梦曾不止一次的提及到：InnoDB从磁盘中读取数据的最小单位是数据页。 而你想得到的id = xxx的数据，就是这个数据页众多行中的一行。 这篇文章我们就一起来看一下数据行设计的多么巧妙。2020-11-11
这篇文章主要介绍了Mac系统下源码编译安装MySQL 5.7.17的教程详解,非常不错，具有参考借鉴价值，需要的朋友可以参考下2017-03-03
这篇文章主要介绍了介绍使用WordPress时10个常用的MySQL查询,许多用户在使用WordPress时选择使用MySQL,本文的整理对于刚刚上手的用户来说非常有用,需要的朋友可以参考下2015-04-04
Win10安装mysql8.0.15 winx64及连接服务器过程中遇到的问题
这篇文章主要介绍了Win10安装mysql8.0.15 winx64及连接服务器过程中遇到的问题,本文通过图文并茂的形式给大家介绍的非常详细，具有一定的参考借鉴价值，需要的朋友可以参考下2019-12-12
这篇文章主要介绍了MySQL使用正则表达式去检索指定数据库字段，文章围绕主题展开详细的内容介绍，具有一定的参考价值，需要的小伙伴可以参考一下2022-09-09
最新评论