文章目录
😊 @ 作者：Lion J💖 @ 主页： https://blog.csdn.net/weixin_69252724🎉 @ 主题：SQL的基础架构⏱️ @ 创作时间：2024年04月24日
————————————————
基础架构
MySQL主要分为Server层服务层,与存储引擎层面
●服务层主要是针对于用户与此次的SQL, 用户是否有权限,SQL的关键词,表名,字段名的判断
●存储引擎层, 主要是和数据打交道, 它与服务层的执行器交互
Server 层基本组件介绍
1) 连接器连接器主要和身份认证和权限相关的功能相关，就好比一个门禁一样。
主要负责用户登录数据库，进行用户的身份认证，包括校验账户密码，权限等操作，如果用户账户密码已通过，连接器会到权限表中查询该用户的所有权限，之后在这个连接里的权限逻辑判断都是会依赖此时读取到的权限数据，也就是说，后续只要这个连接不断开，即使管理员修改了该用户的权限，该用户也是不受影响的。
2) 查询缓存(MySQL 8.0 版本后移除)查询缓存主要用来缓存我们所执行的 SELECT 语句以及该语句的结果集。
连接器建立后，执行查询语句的时候，会先查询缓存，MySQL 会先校验这个 SQL 是否执行过，以 Key-Value 的形式缓存在内存中，Key 是查询语句，Value 是结果集。如果缓存 key 被命中，就会直接返回给客户端，如果没有命中，就会执行后续的操作，完成后也会把结果缓存起来，方便下一次调用。
当然在真正执行缓存查询的时候还是会校验用户的权限，是否有该表的查询条件。
MySQL 查询不建议使用缓存，因为查询缓存失效在实际业务场景中可能会非常频繁，假如你对一个表更新的话，这个表上的所有的查询缓存都会被清空。对于不经常更新的数据来说，使用缓存还是可以的。所以，一般在大多数情况下我们都是不推荐去使用查询缓存的。
MySQL 8.0 版本后删除了缓存的功能，官方也是认为该功能在实际的应用场景比较少，所以干脆直接删掉了。
3) 分析器分析器主要是用来分析该SQL是用来干嘛的, 查询还是更新操作
①分析器主要获取SQL的关键字(如select), 操作的表名, 操作的字段名, 以及查询的条件等..
②根据获取到的语法分析，主要就是判断你输入的 SQL 是否正确，是否符合 MySQL 的语法
接下来就开始进入优化器的环节了
- 优化器
优化器的作用就是它认为的最优的执行方案去执行，比如多个索引的时候该如何选择索引，多表查询的时候如何选择关联顺序等。可以说，经过了优化器之后可以说这个语句具体该如何执行就已经定下来。
5) 执行器
执行器当选择了执行方案后，MySQL 就准备开始执行了，首先执行前会校验该用户有没有权限，如果没有权限，就会返回错误信息，如果有权限，就会去调用引擎的接口，返回接口执行的结果。
语法分析
针对于SQL在MySQL里的执行流程, 主要将SQL分成两个大类, 查询语句select 与 更新语句 (update,delete,insert)
查询语句
查询语句是比较好理解的,按照上面的5个流程来依次执行
select * from A where age='18' and name=' jwq ';
- 先检查该语句是否有权限，如果没有权限，直接返回错误信息，如果有权限，在 MySQL8.0 版本以前，会先查询缓存，以这条 SQL 语句为 key 在内存中查询是否有结果，如果有直接缓存，如果没有，执行下一步。
- ●通过分析器进行词法分析，提取 SQL 语句的关键元素，比如提取语句是查询 select，提取需要查询的表名，需要查询所有的列，查询条件where后面的条件。
●然后判断这个 SQL 语句是否有语法错误，比如关键词是否正确等等，如果检查没问题就执行下一步。- 接下来就是优化器进行确定执行方案，上面的 SQL 语句，可以有两种执行方案：a.先查询学生表中姓名为“jwq”的学生，然后判断是否年龄是 18。b.先找出学生中年龄 18 岁的学生，然后再查询姓名为“jwq ”的学生。那么优化器根据自己的优化算法进行选择执行效率最好的一个方案（优化器认为，有时候不一定最好）。
- 那么确认了执行计划后就准备开始执行了。进行权限校验，如果没有权限就会返回错误信息，如果有权限就会调用数据库引擎接口，返回引擎的执行结果
更新语句
update tb_student A set A.age='15' where A.name='jwq';
这条语句也基本上会沿着上一个查询的流程走，只不过执行更新的时候肯定要记录日志，这就会引入日志模块了，MySQL 自带的日志模块是 binlog（归档日志） ，所有的存储引擎都可以使用，我们常用的 InnoDB 引擎还自带了一个日志模块 redo log（重做日志）
流程如下：
- 先查询到张三这一条数据，不会走查询缓存，因为更新语句会导致与该表相关的查询缓存失效。
- 然后拿到查询的语句，把 age 改为 19
- 然后调用引擎 API 接口，写入这一行数据，InnoDB 引擎把数据保存在内存中，同时记录 redo log，此时 redo log 进入 prepare 状态
- 然后告诉执行器，执行完成了，随时可以提交。执行器收到通知后记录 binlog
然后调用引擎接口，提交 redo log 为提交状态。更新完成。
●为什么要有两个日志?
这是因为最开始 MySQL 并没有 InnoDB 引擎（InnoDB 引擎是其他公司以插件形式插入 MySQL ），MySQL 自带的引擎是 MyISAM，但是我们知道 redo log 是 InnoDB 引擎特有的，其他存储引擎都没有，这就导致会没有 crash-safe 的能力(crash-safe 的能力即使数据库发生异常重启，之前提交的记录都不会丢失)，binlog 日志只能用来归档。并不是说只用一个日志模块不可以，只是 InnoDB 引擎就是通过 redo log 来支持事务的。
其他提交的情况分析
●先写 redo log 直接提交，然后写 binlog，假设写完 redo log 后，机器挂了，binlog 日志没有被写入，那么机器重启后，这台机器会通过 redo log 恢复数据，但是这个时候 binlog 并没有记录该数据，后续进行机器备份的时候，就会丢失这一条数据，同时主从同步也会丢失这一条数据。
●先写 binlog，然后写 redo log，假设写完了 binlog，机器异常重启了，由于没有 redo log，本机是无法恢复这一条记录的，但是 binlog 又有记录，那么和上面同样的道理，就会产生数据不一致的情况。如果采用 redo log 两阶段提交的方式就不一样了，写完 binlog 后，然后再提交 redo log 就会防止出现上述的问题，从而保证了数据的一致性。
极端情况
假设 redo log 处于预提交状态，binlog 也已经写完了，这个时候发生了异常重启会怎么样呢？
这个就要依赖于 MySQL 的处理机制了，MySQL 的处理过程如下：
- 判断 redo log 是否完整，如果判断是完整的，就立即提交。
- 如果 redo log 只是预提交但不是 commit 状态，这个时候就会去判断 binlog 是否完整，如果完整就提交 redo log, 不完整就回滚事务。这样就解决了数据一致性的问题
