mysql索引失效的十大问题小结-巨人网络通讯

主页 > 知识库 > mysql索引失效的十大问题小结

mysql索引失效的十大问题小结

背景
一、查询条件包含or，可能导致索引失效
二、如何字段类型是字符串，where时一定用引号括起来，否则索引失效
三、like通配符可能导致索引失效。
四、联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
五、在索引列上使用mysql的内置函数，索引失效。
六、对索引列运算（如，+、-、*、/），索引失效。
七、索引字段上使用（！= 或者 >，not in）时，可能会导致索引失效。
八、索引字段上使用is null， is not null，可能导致索引失效。
九、左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
十、mysql估计使用全表扫描要比使用索引快,则不使用索引。
总结

背景

最近生产爆出一条慢sql，原因是用了or和!=，导致索引失效。于是，总结了索引失效的十大杂症，希望对大家有帮助，加油。

一、查询条件包含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和场景，具体分析 ，而不是按部就班，墨守成规，认定哪个情景一定索引失效。

到此这篇关于mysql索引失效的十大问题的文章就介绍到这了,更多相关mysql索引失效的十大问题内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

mysql回表致索引失效案例讲解
解决mysql模糊查询索引失效问题的几种方法
MySQL索引失效的典型案例
mysql索引失效的几种情况分析
MySQL索引失效的几种情况详析
MySQL索引失效的几种情况汇总
mysql索引失效的五种情况分析
Mysql索引会失效的几种情况分析

标签：铜川仙桃黄山崇左湘潭衡水湖南兰州

巨人网络通讯声明：本文标题《mysql索引失效的十大问题小结》，本文关键词；如发现本文内容存在版权问题，烦请提供相关信息告之我们，我们将及时沟通与处理。本站内容系统采集于网络，涉及言论、版权与本站无关。

电销机器人到底如何运作的？

很多人对电销机器人到底如何运作存在着巨大的好奇心，那么今天，小编就带大家看一下机器人的运作流程！电销...

10-24

电话机器人的兴起对电销行业来说是“惊喜”还

随着互联网大数据的普及，许多电销行业如雨后春笋般争先恐后地冒出来。而今电销行业的混乱，让各位涉足电销...

10-24

百应电话机器人有哪些功能？百应电话机器人好

百应智能电话机器人能够协助企业进行呼入接待、外呼回访等服务场景，能够经过不断的培训学习，逐步完善成专...

10-24

客服外呼系统都有哪些优势？

当前呼叫中心电话系统被企业用于业务电销以及客户服务，然而随着企业需求不断扩大，原来传统的自建呼叫中心...

10-24

电销机器人效果怎么样？智能电话机器人可行吗

几百数千年后，或许没人会记得卡斯帕罗夫曾是世界第一的围棋高手，但人们会记得，他败给了电脑深蓝。那虽算不...

10-24

百应智能外呼系统，贷后管理科技升级

去年底开始，接连出台政策和法规加强对消费金融等金融形态进行规范。强监管下，行业走向规范发展，行业竞...

10-24

百应智能外呼系统引领外呼行业新风向

电话销售：您好，我这边是XX地产，给您推荐一下精装酒店式公寓，有兴趣了解一下吗? 客户：具体位置在哪里啊?...

10-24

小贷企业为什么需要电销机器人？

随着信贷行业逐步进入我们的生活中，越来越多人选择借款来处理资金难题。信贷企业不断涌现，业务开展迅猛，行...

10-24

雷霆电话机器人是如何转接人工的？

当我们在拨通移动、联通或电信运营商的客服电话时，总会要先经过一些机械化的选择，然后成功连接人工坐席反馈...

10-24

米卡迪电话机器人效果怎么样？

外呼电话机器人，之所以能智能的与客户无忧交流，因为运用了下面这么多高技术。 ASR 语音识别米卡迪电话机器人...

10-24

灵声电话机器人效果怎么样？好用吗

外呼电话机器人，之所以能智能的与客户无忧交流，因为运用了下面这么多高技术。灵声电话机器人效果怎么样？...

10-24

电销机器人要想效果好，话术定制有多重要

电话机器人是基于智能语音技术的智能营销工具。它会像真人一样主动拨打客户的电话，介绍产品并回答客户的咨询...

10-24

智能电话机器人的实现原理，使用安全吗？

随着科学技术的进步和人工智能的发展，越来越多的智能产品已经进入我们的工作和生活。智能手机、智能电视、智...

10-24

福州哪里有电话机器人研发公司？

人工智能再次成为各行各业关注的焦点，自从这个概念首次提出以来，60年已经过去了。自从AlphaGo以巨大优势击败人...

10-24

电销机器人销售能力怎么样？

自从电话机器人一出现，在电销行业火爆了起来。面对电话机器人的各种优势，企业跃跃欲试，但又害怕效果不理...

10-24

推荐文章

python flask开发的简单基金查询工具

科大讯飞闪耀世界人工智能大会：人工智能+未来已来

ADO.NET基础知识汇总

微软Windows Server 2019首个预览版Build 17623发布（附下载地址）

网络传播和下载的版权补偿金制度的适用

vssvc.exe是什么进程

营销缺位：避暑经济还需发出“好声音”

商标转让,知意商标转让网,公司注册、商标注册和品牌注册三者的区别？

上一篇：mysql隔离级别详解及示例

下一篇：Mysql prepare预处理的具体使用

一起分享吧

mysql索引失效的十大问题小结

目录

背景

一、查询条件包含or，可能导致索引失效

二、如何字段类型是字符串，where时一定用引号括起来，否则索引失效

三、like通配符可能导致索引失效。

四、联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。

五、在索引列上使用mysql的内置函数，索引失效。

六、对索引列运算（如，+、-、*、/），索引失效。

七、索引字段上使用（！= 或者 >，not in）时，可能会导致索引失效。

八、索引字段上使用is null， is not null，可能导致索引失效。

九、左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。

十、mysql估计使用全表扫描要比使用索引快,则不使用索引。

总结

QQ咨询

电话咨询