MySQL 全景图

本文主要是介绍MySQL 全景图，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

MySQL 是啥？我一直以为 MySQL 是数据库，直到我最近看了很多关于 MySQL 的文章、专栏以及书籍后，我对 MySQL 的才有了更加深刻的体会。

原来 MySQL 并不是数据库，又或者说，我认为“ MySQL 是数据库这种想法”是片面的。其实MySQL 是一个数据库管理系统，并不只是数据库那么简单。反正我也说不清 MySQL 是什么，这个东西一两句话很难说的清，即使我用一两句话说得清，我相信你也不一定听得懂，这种东西只可意会不可言传。我刚刚不是说了 MySQL 是一个数据库管理系统嘛，我脑子里的MySQL的系统架构是这样的，你看看能不能看得懂：

我看了好多文章，他们都用了很多自己的方式去讲述 MySQL 的架构，比如讲解一条语句在MySQL 的执行过程。其实这是一个很好的想法，但是事实上，他们也没讲明白这个问题，或者说讲不出我想要的那种效果。感觉这些文章要么讲的太粗略，要么没讲到本质。

所以我想写这么一篇文章，把一条语句在 MySQL 的执行过程这个问题给讲好，通过讲这么个问题，将我脑里的 MySQL 全景图描绘出来，顺便梳理一下我的近期所学和收获。

连接器

这相当于 MySQL 架构的入口了。客户端想要拿到 MySQL 系统中数据库的数据，就必须先经过这个连接器与 MySQL 系统建立连接。建立连接的过程采用了三次握手技术。

分析器

这个没啥好讲的。反正就是一条 sql 语句进来，分析器会通过词法分析算法和语法分析算法来判断这条 sql 语句想干嘛，然后把这条语句翻译给优化器听。

优化器

分析器已经将 sql 语句翻译给优化器听了。优化器会看看这条语句有没有索引，有的话就会分析一下到底选择走哪个索引一条 sql 语句执行的很慢的原因有哪些？-CSDN博客（或者多表关联语句的话，决定执行的先后顺序）。把索引选出来之后，将索引交给执行器。

执行器

执行器的执行十分依赖存储引擎。执行器拿到索引时，会调用存储引擎接口，让存储引擎接口帮它做事。存储引擎有很多种，InnoDB、MyISAM、Memory。我们这里就讲 InnoDB 这种。

InnoDB 存储引擎会怎么做呢？它会通过优化器选择的索引（或者说优化器选择的索引B+树谈谈 MySQL 的索引-CSDN博客）来找到想要访问的数据的所在位置。这里特别注意，索引和目录很像，你看书是通过目录来找到你想看的文章的所在页，这里的索引就是目录，想要访问的数据就是想要看的文章，数据所在位置就是书的页码。事实上，我们都知道B+树中叶子节点会存放一些东西，我之前以为叶子节点存放的是数据，后来我发现我理解错了，叶子节点存放的是指针，指针指向数据。数据其实根本不存在于索引树中，而是存在于数据页中。

扯远了，回到刚才说的，当存储引擎找到你想找的数据的所在位置时，存储引擎会看看这个数据在不在 buffer pool 中，如果不在就先将这个数据所在的数据页以及这个数据页的相邻数据页都加载到 buffer pool 中，然后将这个数据交给执行器执行。执行器执行完这个数据后（比如更新这个数据），存储引擎就将这个更新后的数据放回到 buffer pool 中，然后通过两阶段提交，redolog 和 binlog 的区别以及两阶段提交-CSDN博客这条数据就更新完了。

而且，当涉及到对磁盘和 buffer pool 的读写时，会涉及到 MySQL中锁谈谈 MySQL 的锁-CSDN博客这个知识。