MySql查询修改都经历什么

╰+攻爆jí腚メ 2023-01-20 08:16 8阅读 0赞

# 查询过程 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 1][]

## Server层 // 存储引擎 ##

*  Server层(核心):

*  连接器

*  创建连接/获取权限/维持/连接管理
 *  mysql -hIP -P端口 -u用户 -p 回车后输入密码
 *  长连接
    
     *  持续有请求,使用同一个连接
     *  长连接会导致内存的 OOM
        
         *  在一个大的查询后进行断开连接,从新连接连接
         *  5.7后,使用 mysql\_reset\_connection 初始化连接资源,恢复到刚刚创建完成时的状态
 *  短连接
    
     *  执行完很少的几次后,断开连接,下次查询在次重新建立一个

*  查询缓存

*   *  查询结果是 key-value 进行判断是查询过,
        
         *  key 查询语句,value 查询结果
            
             *  有数据结果,直接返回
             *  如果没有继续下面的步骤
             *  数据放在内存中的
 *   *  mysql 5.6版本后不在支持查询缓存了,[官方解释][Link 1]
     *  在MySQL 5.7的生存期内将继续支持查询缓存。MySQL 8.0将不支持查询缓存，并且鼓励用户升级使用服务器端查询重写或ProxySQL作为中间人缓存

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 2][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 3][]

*  分析器

*   *  进行语法分析
        
         *  先 From On Join where 生成新的解析树
         *  内建解析树
         *  判断是否满足Mysql 的语法
         *  错误
            
             *  收到的提示: You have an error in your SQL syntax
             *  重点关心:use near 后面的内容

*  优化器Optimizer
    
     *  确定语句的执行方案
     *  索引的选择
 *  执行器
    
     *  表的执行权限判断
     *  根据表的存储引擎进行去判断
 *  内置函数
 *  存储引擎:
    
     *  数据的存储和提取
     *  架构模式: 插件式
     *  (mysql 5.5.5)默认使用的是:innoDB: ,同时支持:innoDB/MylSAM/Memory 多个存储引擎
     *  不同存储引擎,存取方式也是不同的,支持的功能也不同,

参数解析:

Connect\_timeout 指的是“连接过程中”的等待时间，

wait\_timeout指的是“连接完成后，使用过程中”的等待时间

# 更新过程 #

问题点:

*  和查询语句有什么区别
 *  恢复到任意的时间点 (通过binlog)
 *  mysql innDB 引擎如何保证数据不丢失的 redo Log
 *

更新图解

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 4][]

### 为什么日志需要两阶段提交日志 ###

两阶段提交为了逻辑的一致性的问题,无论redo Log 或者 binLog 前后都有问题的,两阶段,为了两者的逻辑一致性

1 先redo Log 没有操作记录binLog,无法回退

2 先binLog 后续回滚,有多余操作,但是之前执行是失败的

### 实际使用场景: ###

1.  数据回滚
2.  创建备份库,减少读库的压力

## **redo Log** 重做日志(做了什么改动) ##

*  顺序写
 *  inndo引擎特有的
 *  物理日志
 *  循环写的
 *  固定大小的
    
     *  时间轴的效果

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 5][]

*  参数
    
     *  redolog日志文件的个数的参数是innodb\_log\_files\_in\_group，日志文件的个数建议设置为3或4
     *  决定每一个日志文件大小的值为innodb\_log\_file\_size，单个日志文件最大值建议设置为 1GB
     *  innodb\_flush\_log\_at\_trx\_commit = 1 的时候 redo Log事务持久化到磁盘中
     *   
 *  状态有哪几种,对应什么情况

### undo Log 回滚日志 ###

### bin Log 归档日志 ###

*  解释:
    
     *  数据库的写入的操作(不包含查询操作),
     *  在service 层记录的 二进制存储
     *  追加写入的
     *  以"事务"形式存储在磁盘中的
        
         *  可以通过mysqlbinlog工具进行解析
         *  可以通过命令进行查看

SHOW BINLOG EVENTS
        [IN 'log_name'] //要查询的binlog文件名
        [FROM pos] 
        [LIMIT [offset,] row_coun

*  配置参数
    
     *  sync\_binlog 设置 = 1 的时候,表示每次事务的binlog都持久化到磁盘,mysql 重启后binlog 不丢失
     *  binlog\_rows\_query\_log\_events 开启
     *  rows\_query\_event 记录原始的sql
 *  模式
    
     *  statment sql 语句
     *  Row 行的内容,更新前,更新后 数据
     *  MIXED

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70]: /images/20221021/b3e0f51ebed54dc183366d1ae2774719.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 1]: /images/20221021/e8302cf252344af293de69a80d7d8e8f.png
[Link 1]: https://mysqlserverteam.com/mysql-8-0-retiring-support-for-the-query-cache/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 2]: /images/20221021/f34ac3fbcee94980a5ef18ba52603eef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 3]: /images/20221021/35800c2cc5a04831b2e4b382a1dce0c6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 4]: /images/20221021/2ef64ebff8b74444b58f8ca27aecdad1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 5]: /images/20221021/95842f33f20843e18fd0b4bd8351282b.png