MySQL基础架构
MySQL 基础架构
说说 MySQL 的架构？
👉 重要程度：⭐⭐⭐⭐
💡 提示：面试官一般不会直接问你 MySQL 基础架构，通常会由“一个 SQL 语句在 MySQL 中的执行流程”类似的问题引出。
你需要搞懂下图每一个组件所提供的主要功能。
MySQL 体系结构可以分为两大块来看，分别是：Server 和存储引擎。
当客户端与 MySQL 建立连接之后，一条 SQL 语句经过 TCP 从客户端传输到 Server ，Server 会先将语句进行词法分析与语法分析，这个工作是分析器做的。
如果语法有问题，那这个错误相信大家都不陌生：You have an error in your SQL syntax; check the manual......
确认语法没问题之后，会再经由优化器来决策这条语句是否需要重写，如何选择驱动表，如何选择合适的索引等操作，目的就是让语句更高效的执行。
我们平日里用的 explain 其实就是让 MySQL 告诉我们它的优化决定策略是怎样的。
至此，MySQL 已经知道该做什么和怎么做了，此时就是执行器干活时候了，它会调用存储引擎的接口来执行语句。
第一个关键点来了。
例如我现在要执行一条select * from yes where name='LiAng';这条语句，name 这一列没有索引。
此时流程如下：
- Server 调用存储引擎的
返回这个表的第一行这个接口，此时 Server 拿到第一行数据。 - Server 通过 where 条件判断 name 是否等于
yes的练级攻略，如果是则放到结果集中，不是则跳过。 - Server 继续调用存储引擎的接口
来下一行！，然后再通过 where 条件来判断。 - 如此循环往复，直到最后一行记录。
- 不会等结果全部收集完毕了才返回给客户端，等集满
net_buffer大小的结果就会发送，也就是边查边发。
从以上流程可以得知，where 的条件如果用不上索引，那是在 Server 层做过滤的，如果你平日 exlplain 时候从 extra 里看到 using where，那就是在 Server 层利用 where 做了过滤的意思。
然后就是存储引擎的接口。MySQL 的存储引擎是插件式的，一个数据库里面的不同表可以用不同的存储引擎，而 Server 都是同一个，所以需要规定好统一的接口，这样 Server 才好调用不同的存储引擎。
像上面提到的返回这个表的第一行就是一个标准的接口，如果 name 这一列有索引的话，那就是走返回符合这个条件的第一行。从这里我们也可以得知走索引更好，因为这样能利用索引快速过滤得到正确的数据，不走索引就是一条一条拉到 Server 层走 where 过滤。
还有就是上面提到的 MySQL 是边查边发的，其实稍微想想就知道，如果 MySQL 要等结果集全了之后再发送数据给客户端，这样的设计不仅慢，而且如此多的查询需要缓存完整的结果集， MySQL 的内存早就挤爆了。
至此，我相信你脑海里应该可以浮现一条 SQL 的执行路径了，你已经有点感觉了。
再来丰富一下上面的图，把优化器之类的加上去。
对了，你可能在别的地方会看到还有个缓存组件，用于查询缓存，具体做法就是将一个查询语句作为 key ，将上一次请求的结果作为 value，存储在缓存组件中，当同样的语句来查询的时候即可立马返回结果，不需要经历词法、语法分析等以下的步骤。
这个东西在 MySQL 8.0 之后就被砍了，并且只要表有数据改动缓存就失效了，在我们常见的 OLTP(联机事务处理) 场景下是个鸡肋，索性就不画了，清爽比较重要。