目录前言如何验证联合索引的有效性多个单一索引进行验证联合索引总结前言后端面试中一定是必问mysql的,在以往的面试中好几个面试官都反馈我Mysql基础不行,今天来着重复习一下自己的弱点知识。在Mysq...
前言
后端面试中一定是必问mysql的,在以往的面试中好几个面试官都反馈我Mysql基础不行,今天来着重复习一下自己的弱点知识。在Mysql调优中索引优化又是非常重要的方法,不管公司的大小只要后端项目中用到了mysql,几乎都会遇到Mysql查询需要优化的需求。经常有时候前端业务没有压力,经常会在管理后台逻辑中遇到mysql统计查询压力,可能是代码写太烂了,哈哈。在日常工作中我遇到过同事建立索引后问我某个查询条件是否能命中索引,我只能说模糊记得最左匹配原则不能准确地告诉别人是否能命中索引,我今天就打算彻底解决这个问题。
如何验证联合索引的有效性
使用explain,在select语句之前使用
explain
关键字,就会返回sql语句执行计划的信息,而不是执行sql。
CREATE TABLE `videos` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`path` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL,
`name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL,
`user` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL,
`like` int DEFAULT NULL,
`unlike` int DEFAULT NULL,
`status` tinyint(1) DEFAULT NULL,
`count` int DEFAULT '0',
`type` tinyint DEFAULT '1' COMMENT '1美女2励志',
PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=36247 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
这个表的内容是一些抖音的视频的视频名称,作者,保存路径,状态等等信息。
来使用explain
关键字试一下执行以下sql语句:
explain select * from videos where `user` like'%BY2girl%'
其中展示的详细信息根据文章主题这里不做详细说明吧,就算根据其他资料稍微理解复制过来,我也记不住。
这里补充说明一下,我直接新建一个B树索引,B树索引一般是默认创建的索引类型,因为相对于哈希索引B树索引可以获得稳定且较好的查询速度,哈希索引更适合适合做精确查询
explain select count(*) from videos where `user` like'%BY2girl%';
可以看到key
关键字那一列使用到了我自己命名的user_key
这个索引
多个单一索引进行验证
explain select * from videos where `user` ='BY2' and `path` = 'BY2' and `name` = 'BY2'
果然使用到了3个索引,但是我一直有一个疑问,在中间的查询条件使用like模糊返回查询,看看命中了哪个索引:
explain select * from videos where `user` ='BY2' and `path` like '%BY2%' and `name` = 'BY2'
结论Mysql会自动对sql语句进行优化,把可以命中的查询条件放在最前面让它们命中索引,用来提高查询速度。这样一个字段增加一个索引无疑增加了表的空间,给表记录的新增和修改操作增加了压力,联合索引可以稍微解决这个问题,接下来就要说联合索引。
联合索引
联合最左匹配原则解释:以建立索引的字段为查询条件,执行查询时候左边的为起点任何连续的索引都能匹配上,当遇到范围查询(>、<、between、like)就会停止匹配
explain select * from videos where `user` ='BY2' and `path` = 'BY2' and `name` = 'BY2'
explain select * from videos where `user` ='BY2' and `path` like '%BY2%' and `name` = 'BY2'
完全没有命中索引,中间被打断了,我自己以为会命中了一个user
也会命中整个联合索引,我还以为mysql会把name
和user
两个字段优化在最前面实现最左原则从而命中整个联合索引,学到了,接下来把这个like查询放在最后:
explain select * from videos where `user` ='BY2' and `path` = 'BY2' and `name` like '%BY2%'
看来是命中了这个联合索引,两个索引的命中直接命中了整个联合索引,验证成功。
在其中侧面了解到,我设置索引的顺序和最左匹配原则的顺序不是一一匹配的,user
, path
这两个字段可能会优化顺序。但是我设置的联合索引的顺序是path
, name
, user
,其中user
, path
中间有一个name
字段的索引,最左匹配原则是依据查询条件来的,跟where 条件顺序相关!
总结
在日常工作中发现阿里云的云数据库会根据数据库热点查询数据自动增加索引,又减轻了某些不会建立索引的人的压力或者减少了建立错误索引的情况,同时自动减少了数据库压力,哈哈。 索引是mysql非常复杂的知识,它又非常重要,后面遇到问题一定要记录下来,亲自实践增加印象,感觉在今天的验证过程中略过了好多复杂的知识,例如一些explain信息的意思,很重要,等到后面遇到了再仔细研究,今天就到这。
到此这篇关于验证Mysql中联合索引的最左匹配原则详情的文章就介绍到这了,更多相关Mysql中联合索引内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!
本文标题为:验证Mysql中联合索引的最左匹配原则详情
- 基于Python制作一个简单的文章搜索工具 2023-07-28
- Numpy中如何创建矩阵并等间隔抽取数据 2023-07-28
- SQL Server 2022 AlwaysOn新特性之包含可用性组详解 2023-07-29
- 在阿里云CentOS 6.8上安装Redis 2023-09-12
- redis清除数据 2023-09-13
- Oracle 删除大量表记录操作分析总结 2023-07-23
- MySQL8.0.28安装教程详细图解(windows 64位) 2023-07-26
- 搭建单机Redis缓存服务的实现 2023-07-13
- Mongodb启动报错完美解决方案:about to fork child process,waiting until server is ready for connections. 2023-07-16
- SQLSERVER调用C#的代码实现 2023-07-29