神奇的 SQL 之 WHERE 条件的提取与应用
mhr18 2024-10-11 13:01 26 浏览 0 评论
问题描述
一条 SQL 在数据库中是如何执行的呢 ?相信很多人都会对这个问题比较感兴趣。但是,感兴趣归感兴趣,你得去追呀,还臆想着她主动到你怀里来 ?
一条 SQL 在数据库中的生命周期涵盖了 SQL 的词法解析、语法解析、权限检查、查询优化、SQL执行等一系列的步骤,是一个相当复杂的过程,不亚于你追她的艰苦历程,不是只言片语就说的完的。但是,大家先别紧张,上面说的那些了,今天一个也不讲,气不气 ?
今天和大家一起来看一下 SQL 生命周期中比较有意思的一个环节
- 给定一条 SQL,如何提取其中的 where 条件 ?
- where 条件中的每个子条件,在 SQL 执行的过程中有分别起着什么样的作用 ?
SQL 执行流程
这是 MySQL 数据库中 SQL 的执行流程,其他数据库应该类似
关系型数据库中的数据组织
关系型数据库中,数据组织涉及到两个最基本的结构:表与索引。表中存储的是完整数据记录,分为堆表和聚簇索引表;堆表中所有的记录无序存储,聚簇索引表中所有的记录则是按照记录主键进行排序存储。索引中存储的是完整记录的一个子集,用于加速记录的查询速度,索引的组织形式,一般均为B+树结构
MySQL 的 InnoDB 采用的是聚簇索引表,数据记录和索引是一起存储的,类似如下
InnoDB 二级索引(非聚簇索引)的结构与聚集索引的结构基本相同,只是叶子节点有些许差别,二级索引的叶子节点存的是索引值 + 主键值,而聚簇索引的叶子节点存的是索引值 + 完整的数据记录,所以通过二级索引查找的过程是先找到该索引值对应的聚集索引的值,然后再通过该聚簇索引值到聚簇索引树上查找对应的完整数据记录,这个过程称为回表!当然也有不需要回表的情况,这里就不展开了
Oracle、DB2、PostgreSQL,MySQL 的 MyISAM 引擎,采用的是堆表形式来存储数据,索引和数据是分开存储的,类似如下
堆表结构中的聚簇索引和二级索引基本就没什么区别了,可以简单的认为聚簇索引的结构和二级索引中的唯一索引的结构是一样的
其实表结构采用何种形式并不重要,因为下面讲的内容在任何表结构中均适用
WHERE 条件的提取
建表 tbl_test 并初始化数据
假设数据数据结构是堆表形式,那么 idx_bcd 索引的结构图大致如下(聚簇索引不一样,类比一下应该可以画出来,我就偷个懒不画了)
组合索引 idx_bcd 上有 b,c,d 三个字段,不包括 a,e 字段,它是先按照 b 字段排序,b 字段相同,则按照 c 字段排序,以此类推
针对上表,我们分析下 SQL:select * from tbl_test where b >= 2 and b < 7 and c > 0 and d != 2 and e != 'a'; 此 SQL 中 WHERE 条件用到了 b,c,d,e 四个字段,而索引 idx_bcd 刚好是建立在 b,c,d 三个字段上,那么走 idx_bcd 索引进行条件过滤应该能提高查询效率,既然走 idx_bcd 索引进行条件过滤,那么我们来思考下以下几个关键问题
三个关键问题
1、上述 SQL,覆盖了 idx_bcd 索引的哪个范围 ?
起始点由 b >= 2,c > 0 决定,所以 2,1,2 是第一个需要检查的索引项
终止点由 b < 7 决定,所以 8,7,8 是第一个不需要检查的索引项, 8,7,8 后面的也无需检索
2、范围确定后,SQL 中还有哪些条件可以使用 idx_bcd 索引来过滤 ?
上面我们已经确认了范围 2,1,2 ~ 8,7,8 ,那么在这个范围内的每一个索引项是不是都满足 WHERE 条件了 ? 很显然不是, 4,0,5 不满足 c > 0 , 2,1,2 不满足 d != 2 ;所以 c,d 列的 where 条件可以通过索引 idx_bcd 来过滤
3、当 idx_bcd 索引物尽其用后,还有哪些条件是无法通过 idx_bcd 索引过滤的 ?
这个很明显, e != 'a' 无法在索引 idx_bcd 上进行过滤,因为索引并未包含 e 列;e 列只在堆表上存在,所以需要将已经满足索引查询条件的记录回表,取出对应的完整数据记录,然后看该数据记录中 e 列值是否满足 e != 'a' 条件
有些小伙伴可能觉得上述 WHERE 条件的抽取具有特殊性,不具普遍性,那么我们抽象出一套放置于所有 SQL 语句皆准的 WHERE 查询条件的提取规则:Index Key (First Key & Last Key),Index Filter,Table Filter,我们们往下仔细看
Index Key
用于确定 SQL 查询在索引中的连续范围(起始点 + 终止点)的查询条件,被称之为Index Key;由于一个范围,至少包含一个起始条件与一个终止条件,因此 Index Key 也被拆分为 Index First Key 和 Index Last Key,分别用于定位索引查找的起始点以终止点
Index First Key
用于确定索引查询范围的起始点;提取规则:从索引的第一个键值开始,检查其在 where 条件中是否存在,若存在并且条件是 =、>=,则将对应的条件加入Index First Key之中,继续读取索引的下一个键值,使用同样的提取规则;若存在并且条件是 >,则将对应的条件加入 Index First Key 中,同时终止 Index First Key 的提取;若不存在,同样终止 Index First Key 的提取
针对 SQL:select * from tbl_test where b >= 2 and b < 7 and c > 0 and d != 2 and e != 'a',应用这个提取规则,提取出来的 Index First Key 为 b >= 2, c > 0 ,由于 c 的条件为 >,提取结束
Index Last Key
用于确定索引查询范围的终止点,与 Index First Key 正好相反;提取规则:从索引的第一个键值开始,检查其在 where 条件中是否存在,若存在并且条件是 =、<=,则将对应条件加入到 Index Last Key 中,继续提取索引的下一个键值,使用同样的提取规则;若存在并且条件是 < ,则将条件加入到 Index Last Key 中,同时终止提取;若不存在,同样终止Index Last Key的提取
针对 SQL:select * from tbl_test where b >= 2 and b < 7 and c > 0 and d != 2 and e != 'a',应用这个提取规则,提取出来的 Index Last Key为 b < 7 ,由于是 < 符号,提取结束
Index Filter
在完成 Index Key 的提取之后,我们根据 where 条件固定了索引的查询范围,那么是不是在范围内的每一个索引项都满足 WHERE 条件了 ? 很明显 4,0,5 , 2,1,2 均属于范围中,但是又均不满足SQL 的查询条件
所以 Index Filter 用于索引范围确定后,确定 SQL 中还有哪些条件可以使用索引来过滤;提取规则:从索引列的第一列开始,检查其在 where 条件中是否存在,若存在并且 where 条件仅为 =,则跳过第一列继续检查索引下一列,下一索引列采取与索引第一列同样的提取规则;若 where 条件为 >=、>、<、<= 其中的几种,则跳过索引第一列,将其余 where 条件中索引相关列全部加入到 Index Filter 之中;若索引第一列的 where 条件包含 =、>=、>、<、<= 之外的条件,则将此条件以及其余 where 条件中索引相关列全部加入到 Index Filter 之中;若第一列不包含查询条件,则将所有索引相关条件均加入到 Index Filter之中
针对 SQL:select * from tbl_test where b >= 2 and b < 7 and c > 0 and d != 2 and e != 'a',应用这个提取规则,提取出来的 Index Filter 为 c > 0 and d != 2 ,因为索引第一列只包含 >=、< 两个条件,因此第一列跳过,将余下的 c、d 两列加入到 Index Filter 中,提取结束
Table Filter
这个就比较简单了,where 中不能被索引过滤的条件都归为此中;提取规则:所有不属于索引列的查询条件,均归为 Table Filter 之中
针对 SQL:select * from tbl_test where b >= 2 and b < 7 and c > 0 and d != 2 and e != 'a',应用这个提取规则,那么 Table Filter 就为 e != 'a'
是不是有点感觉了 ? 相信此刻,大家对 where 条件的提取基本清楚了,但怎么应用了 ?
WHERE 条件的应用
SQL 语句中的 where 条件,最终都会被提取到 Index Key (First Key & Last Key),Index Filter 与 Table Filter 之中,那么 where 条件的应用,其实就是 Index Key (First Key & Last Key),Index Filter 与Table Filter 的应用
Index First Key,只是用来定位索引的起始点,因此只在索引第一次Search Path(沿着索引B+树的根节点一直遍历,到索引正确的叶节点位置)时使用,只会判断一次
Index Last Key,用来定位索引的终止点,因此对于起始点之后读到的每一条索引记录,均需要判断是否满足 Index Last Key,若不满足,则当前查询结束
Index Filter,用于过滤索引范围中不满足条件的索引项,因此对于索引范围中的每一条索引项,均需要与 Index Filter 进行匹对,若不满足 Index Filter 则直接丢弃,继续读取索引下一条记录
Table Filter,用于过滤不能被索引过滤的条件,此时的索引项已经满足了 Index First Key 与 Index Last Key 构成的范围,并且满足 Index Filter 的条件,但是索引项无法过滤 Table Filter 中的条件,所以回表读取完整的数据记录,判断完整记录是否满足 Table Filter 中的查询条件,若不满足,跳过当前记录,继续读取索引项的下一条索引项,若满足,则返回记录,此记录满足了 where 的所有条件,可以返回给客户端
总结
1、SQL 语句中的 where 条件,最终都会被提取到 Index Key (First Key & Last Key),Index Filter 与 Table Filter ,提取规则需要大家好好体会下
2、数据库中 where 条件的过滤是 one by one(一条一条)的方式进行的,联表查询其实也是 one by one 的方式进行的;虽然我们在开发中感觉到不是 one by one,那其实是数据库驱动做了处理
3、Index Key 的提取,需要考虑到间隙锁,避免幻读问题,有兴趣的小伙伴可以去琢磨下
4、MySQL 5.6 中引入的 Index Condition Pushdown,究竟是 Push Down 了什么,从哪 Push Down 到哪 ? 大家可以先去了解下,我们下篇详细讲解
相关推荐
- 订单超时自动取消业务的 N 种实现方案,从原理到落地全解析
-
在分布式系统架构中,订单超时自动取消机制是保障业务一致性的关键组件。某电商平台曾因超时处理机制缺陷导致日均3000+订单库存锁定异常,直接损失超50万元/天。本文将从技术原理、实现细节、...
- 使用Spring Boot 3开发时,如何选择合适的分布式技术?
-
作为互联网大厂的后端开发人员,当你满怀期待地用上SpringBoot3,准备在项目中大显身手时,却发现一个棘手的问题摆在面前:面对众多分布式技术,究竟该如何选择,才能让SpringBoot...
- 数据库内存爆满怎么办?99%的程序员都踩过这个坑!
-
你的数据库是不是又双叒叕内存爆满了?!服务器监控一片红色警告,老板在群里@所有人,运维同事的电话打爆了手机...这种场景是不是特别熟悉?别慌!作为一个在数据库优化这条路上摸爬滚打了10年的老司机,今天...
- springboot利用Redisson 实现缓存与数据库双写不一致问题
-
使用了Redisson来操作Redis分布式锁,主要功能是从缓存和数据库中获取商品信息,以下是针对并发时更新缓存和数据库带来不一致问题的解决方案1.基于读写锁和删除缓存策略在并发更新场景下,...
- 外贸独立站数据库炸了?对象缓存让你起死回生
-
上周黑五,一个客户眼睁睁看着服务器CPU飙到100%——每次页面加载要查87次数据库。这让我想起2024年Pantheon的测试:Redis缓存能把WooCommerce查询速度提升20倍。跨境电商最...
- 手把手教你在 Spring Boot3 里纯编码实现自定义分布式锁
-
为什么要自己实现分布式锁?你是不是早就受够了引入各种第三方依赖时的繁琐?尤其是分布式锁这块,每次集成Redisson或者Zookeeper,都得额外维护一堆配置,有时候还会因为版本兼容问题头疼半...
- 如何设计一个支持百万级实时数据推送的WebSocket集群架构?
-
面试解答:要设计一个支持百万级实时数据推送的WebSocket集群架构,需从**连接管理、负载均衡、水平扩展、容灾恢复**四个维度切入:连接层设计-**长连接优化**:采用Netty或Und...
- Redis数据结构总结——面试最常问到的知识点
-
Redis作为主流的nosql存储,面试时经常会问到。其主要场景是用作缓存,分布式锁,分布式session,消息队列,发布订阅等等。其存储结构主要有String,List,Set,Hash,Sort...
- skynet服务的缺陷 lua死循环
-
服务端高级架构—云风的skynet这边有一个关于云风skynet的视频推荐给大家观看点击就可以观看了!skynet是一套多人在线游戏的轻量级服务端框架,使用C+Lua开发。skynet的显著优点是,...
- 七年Java开发的一路辛酸史:分享面试京东、阿里、美团后的心得
-
前言我觉得有一个能够找一份大厂的offer的想法,这是很正常的,这并不是我们的饭后谈资而是每个技术人的追求。像阿里、腾讯、美团、字节跳动、京东等等的技术氛围与技术规范度还是要明显优于一些创业型公司...
- mysql mogodb es redis数据库之间的区别
-
1.MySQL应用场景概念:关系型数据库,基于关系模型,使用表和行存储数据。优点:支持ACID事务,数据具有很高的一致性和完整性。缺点:垂直扩展能力有限,需要分库分表等方式扩展。对于复杂的查询和大量的...
- redis,memcached,nginx网络组件
-
1.理解阻塞io,非阻塞io,同步io,异步io的区别2.理解BIO和AIO的区别io多路复用只负责io检测,不负责io操作阻塞io中的write,能写多少是多少,只要写成功就返回,譬如准备写500字...
- SpringBoot+Vue+Redis实现验证码功能
-
一个小时只允许发三次验证码。一次验证码有效期二分钟。SpringBoot整合Redis...
- AWS MemoryDB 可观测最佳实践
-
AWSMemoryDB介绍AmazonMemoryDB是一种完全托管的、内存中数据存储服务,专为需要极低延迟和高吞吐量的应用程序而设计。它与Redis和Memcached相似,但具有更...
- 从0构建大型AI推荐系统:实时化引擎从工具到生态的演进
-
在AI浪潮席卷各行各业的今天,推荐系统正从幕后走向前台,成为用户体验的核心驱动力。本文将带你深入探索一个大型AI推荐系统从零起步的全过程,揭示实时化引擎如何从单一工具演进为复杂生态的关键路径。无论你是...
你 发表评论:
欢迎- 一周热门
-
-
Redis客户端 Jedis 与 Lettuce
-
高并发架构系列:Redis并发竞争key的解决方案详解
-
redis如何防止并发(redis如何防止高并发)
-
Java SE Development Kit 8u441下载地址【windows版本】
-
开源推荐:如何实现的一个高性能 Redis 服务器
-
redis安装与调优部署文档(WinServer)
-
Redis 入门 - 安装最全讲解(Windows、Linux、Docker)
-
一文带你了解 Redis 的发布与订阅的底层原理
-
Redis如何应对并发访问(redis控制并发量)
-
Oracle如何创建用户,表空间(oracle19c创建表空间用户)
-
- 最近发表
- 标签列表
-
- oracle位图索引 (74)
- oracle批量插入数据 (65)
- oracle事务隔离级别 (59)
- oracle主从同步 (56)
- oracle 乐观锁 (53)
- redis 命令 (83)
- php redis (97)
- redis 存储 (67)
- redis 锁 (74)
- 启动 redis (73)
- redis 时间 (60)
- redis 删除 (69)
- redis内存 (64)
- redis并发 (53)
- redis 主从 (71)
- redis同步 (53)
- redis结构 (53)
- redis 订阅 (54)
- redis 登录 (62)
- redis 面试 (58)
- redis问题 (54)
- 阿里 redis (67)
- redis的缓存 (57)
- lua redis (59)
- redis 连接池 (64)