这是我参与「第五届青训营 」伴学笔记创作活动的第 18 天
今日学习
- 数据库的历史
- 数据库的执行过程
- 数据库的概念
SQL执行
SQL引擎
查询解析：SQL 语言接近自然语言，入门容易。但是各种关键字、操作符组合起来，可以表达丰富的语意。因此想要处理SQL命令，首先将文本解析成结构化数据，也就是抽象语法树 （AST）。 查询优化：SQL 是一门表意的语言，只是说『要做什么』，而不说『怎么做』。所以需要一些复杂的逻辑选择『如何拿数据』，也就是选择一个好的查询计划。优化器的作用根据AST优化产生最优执行计划（Plan Tree）。 查询执行：根据查询计划，完成数据读取、处理、写入等操作。 事务引擎：处理事务一致性、并发、读写隔离等 存储引擎：内存中的数据缓存区、数据文件、日志文件
过程如下
所有的代码在执行之前，都存在一个解析编译的过程，差异点无非在于是静态解析编译还是动态的。
解析编译
SQL语言也类似，在SQL查询执行前的第一步就是查询解析。
词法分析：将一条SQL语句对应的字符串分割为一个个token，这些token可以简单分类。
语法分析：把词法分析的结果转为语法树。根据tocken序列匹配不同的语法规则，比如这里匹配的是update语法规则，类似的还有insert、delete、select、create、drop等等语法规则。根据语法规则匹配SQL语句中的关键字，最终输出一个结构化的数据结构。
语义分析：对语法树中的信息进行合法性校验。
sql优化
基于规则的优化(RBO Rule Base Optimizer)
基于代价的优化（CBO Cost Base Optimizer)
其实，对于用户只能感知到查询时间这个代价，底层用了多少资源他是不在乎的。但是在并发的情况下，就得考虑资源消耗了，这个用户的查询占用的资源多了，其他用户的资源就少了。所以资源也是必须考虑的一点。
对于InnoDB 存储引擎来说，全表扫描的意思就是把聚簇索引中的记录都依次和给定的搜索条件做一下比较，把符合搜索条件的记录加入到结果集，所以需要将聚簇索引对应的页面加载到内存中，然后再检测记录是否符合搜索条件。
对于使用二级索引 + 回表方式的查询，设计MySQL 的计算这种查询的成本依赖两个方面的数据：范围区间数量，需要回表数据量
执行
Plan Tree为基础 调用关系是由根到叶 数据流是从叶到根
火山模型
编译执行
就是先将基础编译执行
储存引擎
- Buffer Pool：存储引擎位于内存中的重要结构，用于缓存数据，减少磁盘IO的开销。
- Page：数据存储的最基本单位，一般为16KB。
- B+u Tree：InnoDB中最常用的索引结构。
Buffer Pool
淘汰那个最近一段时间最少被访问过的缓存页了，这种思想就是典型的 LRU 算法了。
普通的LRU算法存在缺陷，考虑我们需要扫描100GB的表，而我们的buffer pool只有1GB，这样就会因为全表扫描的数据量大，需要淘汰的缓存页多，导致在淘汰的过程中，极有可能将需要频繁使用到的缓存页给淘汰了，而放进来的新数据却是使用频率很低的数据。
MySQL 确实没有直接使用 LRU 算法，而是在 LRU 算法上进行了优化。 MySQL 的优化思路就是：对数据进行冷热分离，将 LRU 链表分成两部分，一部分用来存放冷数据，也就是刚从磁盘读进来的数据，另一部分用来存放热点数据，也就是经常被访问到数据。
当从磁盘读取数据页后，会先将数据页存放到 LRU 链表冷数据区的头部，如果这些缓存页在 1 秒之后被访问，那么就将缓存页移动到热数据区的头部；如果是 1 秒之内被访问，则不会移动，缓存页仍然处于冷数据区中。 淘汰时，首先淘汰冷数据区。
Page
B+ Tree
事务引擎
事务引擎实现了数据库的ACID能力，
- Atomicity：InnoDB中通过undo日志实现了数据库的原子性，通过Undo Log，数据库可以回滚到事务开始的状态；
- Isolation：通过Undo Log实现MVCC（多版本并发控制），降低读写冲突。
- Durability：通过Redo Log（一种WAL实现方式）来保证事务在提交后一定能持久化到磁盘中。
- Consistency：一致性本质上是一种业务层的限制
学习总结
数据库的执行过程，非常的全面的但是不够详细，这几节课能够深化我对数据库的理解
