全面理解Mysql架构
mysql官方文档：https://dev.mysql.com/doc/refman/8.0/en/installing.html
安装Mysql
-
Centos7中安装Mysql
-
通过Docker安装Mysql
在Docker中运行的Mysql与实体机中相比，虽说性能上略有不如，不过却可以很方便地帮我们拉起一个集群。
mkdir -p /home/mysql8/data /home/mysql8/config /home/mysql8/logsdocker 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
-
Centos7中安装Mysql
-
通过Docker安装Mysql
在Docker中运行的Mysql与实体机中相比，虽说性能上略有不如，不过却可以很方便地帮我们拉起一个集群。
mkdir -p /home/mysql8/data /home/mysql8/config /home/mysql8/logsdocker 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主要由连接器、分析器、优化器、执行器，以及存储引擎组成
- 当客户端一个连接请求过来时，首先由连接器校验该用户是否有建立连接的权限（如
mysql -uroot -p） - 分析器：分析编写的sql是否符合规则（验证表执行权限）
- 词法分析：information_schema表中记录了表字段信息，检测出操作的字段是否存在（
1054 - Unknown column 'NAME' in 'field list'） - 语法分析：sql语法不对，会提示错误大概的位置near by（
You have an error in your SQL syntax）
- 词法分析：information_schema表中记录了表字段信息，检测出操作的字段是否存在（
- 优化器：在一个查询语句的查询方案中选出最优解，如表连接中小表驱动大表
- 执行器：最终去执行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层。
执行一条更新语句：
- 首先拿到记录并更新，
- 写入内存
- 写入到redolog（此时redolog的状态是prepare，还没有正式写入redolog日志文件）
- 写入binlog
- 提交事务，此时redolog的状态为commit
若是binlog更新完，还没来得及commit，数据库突然崩溃，重启mysql之后能够恢复嘛？
可以的，重启之后发现redolog是prepare状态，则回去检查binlog的数据是否完整。若binlog数据完整则直接提交，否则回滚数据