全面理解Mysql架构

全面理解Mysql架构

mysql官方文档：https://dev.mysql.com/doc/refman/8.0/en/installing.html

安装Mysql

1. Centos7中安装Mysql

2. 通过Docker安装Mysql

在Docker中运行的Mysql与实体机中相比，虽说性能上略有不如，不过却可以很方便地帮我们拉起一个集群。

mkdir -p /home/mysql8/data /home/mysql8/config  /home/mysql8/logs

docker run  -d  \
--name mysql8 \
--privileged=true \
--restart=always \
-p 3310:3306 \
-v /home/mysql8/data:/var/lib/mysql \
-v /home/mysql8/config:/etc/mysql/conf.d  \
-v /home/mysql8/logs:/logs \
-e MYSQL_ROOT_PASSWORD=123456 \
-e TZ=Asia/Shanghai mysql:8.0.27 \
--lower_case_table_names=1  

全面理解Mysql架构

安装Mysql

1. Centos7中安装Mysql

2. 通过Docker安装Mysql

在Docker中运行的Mysql与实体机中相比，虽说性能上略有不如，不过却可以很方便地帮我们拉起一个集群。

mkdir -p /home/mysql8/data /home/mysql8/config  /home/mysql8/logs

docker run  -d  \
--name mysql8 \
--privileged=true \
--restart=always \
-p 3310:3306 \
-v /home/mysql8/data:/var/lib/mysql \
-v /home/mysql8/config:/etc/mysql/conf.d  \
-v /home/mysql8/logs:/logs \
-e MYSQL_ROOT_PASSWORD=123456 \
-e TZ=Asia/Shanghai mysql:8.0.27 \
--lower_case_table_names=1  

了解mysql的架构

mysql的查询与更新流程

Mysql主要由连接器、分析器、优化器、执行器，以及存储引擎组成

1. 当客户端一个连接请求过来时，首先由连接器校验该用户是否有建立连接的权限（如mysql -uroot -p）
2. 分析器：分析编写的sql是否符合规则（验证表执行权限）
   1. 词法分析：information_schema表中记录了表字段信息，检测出操作的字段是否存在（1054 - Unknown column 'NAME' in 'field list'）
   2. 语法分析：sql语法不对，会提示错误大概的位置near by（You have an error in your SQL syntax）
3. 优化器：在一个查询语句的查询方案中选出最优解，如表连接中小表驱动大表
4. 执行器：最终去执行sql语句。需要验证执行权限

为什么表的执行权限在分析器中已经验证过了，到了执行器中又重复验证一边呢？
因为由触发器、存储过程等附带的表，只有到执行的时候才知道有没有权限

5.查询缓存：之前查询过一次的sql会放在查询缓存中，命中率太低，且影响并发，所以在mysql8中已经废除了

更新语句的流程：update T set c=c+1 where ID=2;

与上面的查询流程大差不差，主要区别就在：通过分析器确定是更新语句、通过优化器确定通过ID来更新记录、最终由执行器更新数据

Redolog与Binlog的二阶段提交（内部XA）

redolog与binlog用来保证mysql崩溃后的数据恢复，其中redolog是Innodb特有的，binlog是数据mysql的server层。

执行一条更新语句：

1. 首先拿到记录并更新，
2. 写入内存
3. 写入到redolog（此时redolog的状态是prepare，还没有正式写入redolog日志文件）
4. 写入binlog
5. 提交事务，此时redolog的状态为commit

若是binlog更新完，还没来得及commit，数据库突然崩溃，重启mysql之后能够恢复嘛？

可以的，重启之后发现redolog是prepare状态，则回去检查binlog的数据是否完整。若binlog数据完整则直接提交，否则回滚数据