mysql 一条sql执行流程

1.1  select语句执行过程

下图是 MySQL 的一个简要架构图,从下图你可以很清晰的看到用户的 SQL 语句在 MySQL 内部是如何执行的。

先简单介绍一下下图涉及的一些组件的基本作用帮助大家理解这幅图,

连接器: 身份认证和权限相关(登录 MySQL)。

查询缓存: 执行查询语句的时候,会先查询缓存(MySQL 8.0 版本后移除,因为这个功能不太实用)。

分析器: 没有命中缓存的话,SQL 语句就会经过分析器,分析器说白了就是要先看你的 SQL 语句要干嘛,再检查你的 SQL 语句语法是否正确。

优化器: 按照 MySQL 认为最优的方案去执行。根据cost开销进行优化,比如走哪条索引、哪个表驱动,选择cost开销最小的执行计划去执行

执行器: 执行语句,然后从存储引擎返回数据

简单来说 MySQL 主要分为 Server 层和存储引擎层:

Server 层:主要包括连接器、查询缓存、分析器、优化器、执行器等,所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图,函数等,还有一个通用的日志模块 binglog 日志模块。

存储引擎: 主要负责数据的存储和读取,采用可以替换的插件式架构,支持 InnoDB、MyISAM、Memory 等多个存储引擎,其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB,它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了。

2. update/insert/delete 语句执行过程

buffer bool : innodb为了提升读写效率,设计了一个缓冲区buffer bool 每次从磁盘读取固定大小的数据存储到缓冲区buffer pool。缓冲区还没有从内存区同步到磁盘的时候,叫做脏页,因为断电等其他操作可能会导致与磁盘数据不一致。由后台线程同步到磁盘,不断进行,动作叫刷脏。刷脏并不是时时进行,在同步过程中如果服务器重启或者断电?这时候数据一致性怎么保证?

redo log:mysql innodb为了解决这种情况设计了redolog,重启后查看redolog中还有没有没同步的数据,若有则同步,实现数据的持久性。那这样设计有什么漏洞吗?

先写内存,又要写redo log ,为什么不直接写磁盘呢?这里引申处个顺序IO和随机IO的问题,读取数据先要找到扇区,磁盘不停转动,如果存储数据是随机存储,需要不停的寻址,叫做随机IO,如果存储的数据在一个块区,叫做顺序IO。redo log 写入日志是采用的是顺序IO,减少了寻址次数,加快IO的读写速度。

redo log 默认 48M ib_logfile0  ib_logfile1 ,记录在某个数据页进行了什么修改,属于物理日志。redolog 写满了触发刷盘操作,可以尽量设置的大一点,延缓redolog 的刷盘频率。

undo log: 记录事物发生之前的数据状态,发生异常时候回滚,保证数据的原子性。作用场景:如果一个操作包含多个sql语句,如果执行了一半失败了,保证所有的sql失败或者成功,实现原子性。没有独立的日志~

根据上述我们可以总结出一条更新语句的执行流程:

update table set name=“new name”

1、事物开始,从内存buffer pool 或磁盘data file 取到这条数据的数据页面,返回给Selver执行器

2.执行器修改这条数据的值如:set name=“new name”

3.记录name = oldname 到 undolog

4.记录name=newname 到 redolog

5.调用存储引擎innodb接口,记录修改后的数据页到buffer pool 

6.事物提交


总结:在buffer pool 即内存中修改,修改完成后提交到磁盘。undolog 记录修改前数据,redolog 记录修改后数据。

log buffer   buffer pool 的内存缓冲区  默认提交事物时候log buffer 提交 进行刷盘。

change buffer 是buffer pool 一部分。若缓冲区数据是非唯一索引,且不存在重复数据,这种情况也就不需要从磁盘中加载数据判断数据非唯一性。可把修改数据放在缓存中,提升读写效率。根据页面场景调整change buffer大小

一般占到机器80%,提高读写效率

buffer pool LRU 内存淘汰算法 ,根据热点数据进行淘汰。新查询或者进来的数据放到头部,不访问的数据放到链表尾部。类似JVM 热数据、冷数据区~

binlog: Server 层日志。非innodb独有。以事件的形式记录的DDL、DML日志,记录的是操作而不是数据值,属于逻辑值。可用于实现主从复制。和数据恢复(需要定时记录全量日志,先恢复全量数据,再根据binlog日志进行数据更新)

崩溃恢复时根据binlog日志记录,判断是否需要提交或回滚,走到了第6步则提交,否则回滚。

3. 总结

MySQL 主要分为 Server 层和引擎层,Server 层主要包括连接器、查询缓存、分析器、优化器、执行器,同时还有一个日志模块(binlog),这个日志模块所有执行引擎都可以共用,redolog 只有 InnoDB 有。

引擎层是插件式的,目前主要包括,MyISAM,InnoDB,Memory 等。

SQL 等执行过程分为两类,一类对于查询等过程如下:权限校验—》查询缓存—》分析器—》优化器—》权限校验—》执行器—》引擎

对于更新等语句执行流程如下:分析器----》权限校验----》执行器—》引擎—redo log prepare—》binlog—》redo log commit

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,384评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,845评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,148评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,640评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,731评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,712评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,703评论 3 415
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,473评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,915评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,227评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,384评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,063评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,706评论 3 324
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,302评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,531评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,321评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,248评论 2 352