MySQL执行流程与架构
MySQL执行流程与架构
一条查询语句是如何执行的？
连接数据库方式
dos命令行、或者Navicat等连接数据库软件
默认的交互时间
非交互式超时时间（如JDBC程序）和交互式超时时间（如数据库工具）默认都是28800秒（8个小时）
默认的最大连接数
默认连接数是151台，5.7版本中允许的最大连接数是10万台。
修改参数方式
动态修改（数据库重启后，恢复默认值）
set max_connections = '连接数';
set autocommit = on;
# 8.0+可用，可直接通过命令修改配置文件
set persit autocommit = on;
永久修改：修改mysql的配置文件（如windows10系统中的my.ini，linux系统中的my.cnf）
参数有两个修改等级(修改影响范围)：GLOBAL(全局)、SESSION(当前窗口)
通信类型
同步（mysql用的是这个）
异步
连接方式
长连接（一般是）
短连接
通信协议
TCP/IP(一般是)
Unix Socket
通讯方式
单工（数据单项传输）
半双工（双向不能同时传递数据）
全双工（双向且可同时传递数据）
单次客户端向服务端发送数据的数据量限制默认为4M
# 查询当前数据传输限制大小
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';
Java中连接数据库的两个对象区别
Statement
PreaparedStatement :拥有批量操作（addBatch()）
执行过程
Query Cache(查询缓存)
Paser（解析器）
词法解析
语法解析
pre processor(预处理)
权限
语义解析
optimizer（优化器）
Execution plans（执行计划）
执行器
Storage Engine(存储引擎)
每一个表都可以有自己的存储引擎，并且可以后期修改，但操作需谨慎。
# 查看该数据库下所有的表属性
SHOW TABLE STATUS FROM 库名;
# 查看数据库的存储引擎设置
SHOW ENGINES;
默认的存储引擎是 InnoDB
每种存储引擎有其特定的规则，其编写语言是c语言，可自己根据规范编写一种存储引擎
MySQL体系结构
一条更新语句是如何执行的？
相同：与查询大部分一致的执行顺序。
不同：
存储引擎需要去磁盘中取数据（单次取，不够的话也会取page页16kb）。
在server层外，与存储引擎中间多了一个内存缓冲区（buffer pool），更新数据缓存其中。
# 查看innodb的系统状态脏页设置
SHOW STATUS LIKE '%innodb_buffer_pool%';
# 查看innodb的系统参数脏页设置 默认为128m
SHOW VARIABLES LIKE '%innodb_buffer_pool%';
bin log:
属于逻辑日志，记录DDL、DML语句，文件大小不固定，随之使用会越来越大。可以通过此文件，实现主从数据库复制。默认关闭。
不能依赖于bin log文件作为数据库备份，应该定期增量对数据库进行备份。
数据库被删除恢复操作：
1、停止数据库的一切操作。
2、使用定期备份的数据，进行数据库恢复。
3、从bin log文件解析出的至定期时间到被删除时间节点的sql语句执行一遍。
4、将删库的drop命令剔除。
问题1：宕机或不定因素造成的内存丢失怎么办？
更新等确定操作之后，将会写入一个redo log文件中，防止数据的丢失。
redo log：
属于物理日志， 在InnoDB存储引擎层实现，用于数据库持久化，记录数据页的改动，存在于mysql的安装路径中，其拥有固定的文件大小，虽然文件大小默认为48m，但可以设置，且其只能做为一个短期数据恢复的风险处理方案，不可作为数据库恢复。因为其早期数据会被覆盖。
问题2：写入日志不写入数据库文件快？效率变低？
因为在buffer pool确认更新数据后，直接写入磁盘中时，使用的是随机I/O，写入时机不定。而写入redo log（物理日志）中，使用的是顺序I/O，更加稳定。
undo log 文件的作用
逻辑日志，在执行新增、修改、删除时，记录下方向操作，保证数据库的原子性，用于出错时的回滚。
# 设置undo log的全局配置
SHOW GLOBAL VARIABLES LIKE '%undo%';
执行详解：
UPDATE USER SET name = 'penyuyan' WHERE id = 1;
1、把磁盘、内存的数据返回给Server
2、修改值为penyuyan
3、修改undo log、redo log
4、调用存储引擎接口，在buffer pool修改name = penyuyan;
5、事务提交（事务提交后，交由后台线程进行处理）
本文地址：https://blog.csdn.net/weixin_43935845/article/details/108846158