03 | 事务隔离



数据库事务的特性是 ACID：
- Atomicity，原子性
- Consistency，一致性
- Isolation，隔离性
- Durability，持久性

本篇笔记侧重讲 **“隔离性”**

常见的隔离性问题有：
- 脏读，dirty read
- 不可重复读，non-repeatable read
- 幻读，phantom read

为解决这些问题，就有了 **“隔离级别”**，SQL 标准的事务隔离级别有：
- 读未提交，read uncommitted
- 读提交，read committed
- 可重复读，repeatable read
- 串行化，serializable


:::note{title="面试题：MySQL 的默认事务隔离级别是什么？"}
- MySQL 默认的事务隔离级别是【可重复读】
- Oracle 默认的事务隔离级别是【读提交】
:::

可以通过启动参数 `transaction-isolation` 修改 MySQL 的默认事务隔离级别，还可以通过 `show variables` 来查看：
```sql
mysql> show variables like 'transaction_isolation';
+-----------------------+----------------+
| Variable_name | Value |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+
```

## 可重复读的实现

MySQL 中每条记录在更新的时候都会记录一条回滚操作，通过对记录上最新值叠加回滚操作，就可以得到之前的值。假设一个值从 1 被按顺序改成了 2、3、4，在回滚日志里面就会有类似下面的记录：

![image.png](/static/img/4c8dba7941e51f7ec69dc9100cbf513b.image.webp)

如图所示，不同时间启动的事务会有不同的视图，即同一条记录在系统中可以有多个版本，这就是数据库的多版本并发控制，即 MVCC.

即使现在有另外一个事务正在将 4 改成 5，这个事务跟 read-view A、B、C 对应的事务是不会冲突的。


:::note{title="回滚日志什么时候删除"}
会在不需要的时候删除
:::

建议不要使用长事务，长事务会在系统中记录很老的事务视图，导致大量占用存储空间。

在 MySQL 5.5 及以前的版本，回滚日志是跟数据字典一起放在 ibdata 文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小。作者见过数据只有 20GB，而回滚段有 200GB 的库。最终只好为了清理回滚段，重建整个库。

## 事务的启动方式

1. 显式启动事务语句
    
    - 启动事务：begin 或 start transaction
    - 提交事务：commit
    - 回滚事务：rollback

2. 通过 `set autocommit=0` 关闭自动提交。关闭后，事务还是会自动启动的，支持要手动 coomit 活 rollback。**建议使用 `set  autocommit=1` 以通过显示语句的方式（即上面第一种方式）启动事务。**

## 如何查询长事务

可以在 information_schema 库的 innodb_trx 这个表中查询长事务。

*查找持续时间超过 60s 的事务*
```sql
select * 
    from information_schema.innodb_trx 
where 
    TIME_TO_SEC(timediff(now(),trx_started)) > 60
```

MySQL 笔记 03

02 | 日志系统：一条 SQL 更新语句是如何执行的？



查询语句的执行流程，更新语句也会同样走一遍：

![image.png](/static/img/361d841f41127b30d4d05b0dc4c97bba.image.webp)

与查询流程不一样的是，更新流程会设计两个重要的日志模块：
- 重做日志，redo log
- 归档日志，binlog

## redo log

WAL 的概念：每次更新都写入磁盘的话，效率会很慢，所有优化一下，先记录到日志，再在某个时机写入到磁盘，这就是 WAL，全称 Write-Ahead Logging。

具体到 InnoDB 来说，当有一条记录需要更新的时候，InnoDB 引擎先把更新数据记录到 redo log 并更新内存，然后 InnoDB 会在空闲的时候将数据写入到磁盘。

InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件 1 GB，那么一共可以记录 4GB 的更新操作数据。如果写满了就回到开头第一个文件循环写：

![image.png](/static/img/59c8e41fe1527e548cce39ea52ba7dea.image.webp)

write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe。

## binlog

之前讲过，MySQL 的架构主要有 Server 层和存储引擎层。redo log 是 InnoDB 存储引擎特有的日志，而 binlog 是 Server 层的。

一开始 MySQL 没有 InnoDB，只有 MyISAM，但是 MyISAM 没有crash-safe 能力。Server 层的 binlog 只能用于归档。

redo log 和 binlog 的不同点：
1. redo log 是 InnoDB 特有的，binlog 是 MySQL Server 层实现的，所有引擎都可以使用
2. redo log 是物理日志，binlog 是逻辑日志
3. redo log 是循环写，binlog 是追加写

## InnoDB 执行更新语句的流程

1. 执行器先找引擎拿到要更新的行，如果该行所在的数据页已经在内存中，则直接返回；否则从磁盘读取内存再返回
2. 执行器对获取到的行数据修改值，调用引擎的写接口写入更新的值
3. 引擎将新值更新到内存，记录到 redo log，标记状态为 prepare，然后告知执行器完成了。
4. 执行器生成更新操作的 binlog，把 binlog 写入磁盘
5. 执行器调用引擎的提交事务接口，引擎把将 redo log 标记改为 commit，更新完成

![image.png](/static/img/3bbd9df647c73deb10846a5f9a6f194a.image.webp)

**注意：** 这个过程中，将写入 redo log 的过程拆分为 prepare 和 commit 的做法，就是两阶段提交。

MySQL 笔记 02

01 | 基础架构：一条SQL语句是如何执行的？
    


![image.png](/static/img/51c5842a0ea2375fad21ef3c345d1d59.image.webp)

## 架构总览

![image.png](/static/img/361d841f41127b30d4d05b0dc4c97bba.image.webp)

MySQL 的架构分为 Server 层和存储引擎层。
其中 Server 层包含：
- 连接器
- 查询缓存
- 分析器
- 优化器
- 执行器

而存储引擎则负责数据的存储的提取，采用插件式架构，支持 InnoDB、MyISAM、Memory 等多种存储引擎。

## 连接器

- 连接器负责跟客户端建立连接、获取权限、维持和管理连接
- 连接后没有后续动作的话，连接会成为空闲连接，可通过 `show processlist` 查看空闲连接
- 默认如果客户端超过 8 小时没有任何活动，连接器会断开连接。可通过 `wait_timeout` 参数控制

## 查询缓存

- **不建议使用查询缓存**，因为只要对一个表更新，这个表的所有查询缓存都会被清空
- 参数 `query_cache_type` 设置为 `DEMAND`，所有 sql 语句默认都不使用查询缓存
- 可以对单条 sql 指定使用查询缓存，`select SQL_CACHE * from T where ID = 10;`

## 分析器

- 先做词法分析，再做语法分析
- 词法分析就是分析一条 sql 中哪些是表名，哪些是字段等
- 语法分析就是检查语法错误

## 优化器

- 如果表有多个索引，优化器可以决定用哪个索引进行查询
- 如果是连接查询，优化器可以决定各个表的连接顺序

## 执行器

1. 如果命中查询缓存，会在返回结果的时候验证权限
2. 如果没有命中查询缓存，会在执行查询前验证权限
3. 如果有权限，根据表的执行引擎，调用执行引擎的接口执行查询。执行步骤：

    3.1 调用引擎获取第一行，判断是否符合查询条件，是则存到结果集中，否则跳过

    3.2 调用执行引擎获取下一行，重复相同的判断，直到遍历到这个表最后一行

    3.3 执行器将结果集返回给客户端

MySQL 笔记 01

tar 打包指定路径





目录结构：
```
ems-server
	├─ _temp
	│	├─ ems-server-src
	│	└─ ems-server-src.tar.gz
	└─ bin
		└─ deploy.ps1    
```

目标实现效果：在任意目录执行打包命令，都可以将 `_temp\ems-server-src` 打包输出到 `_temp\ems-server-src.tar.gz`，并且 `ems-server-src.tar.gz` 解压出来后不会嵌套多层父级路径的目录。

命令格式：
```powershell
tar -czf <打包文件输出的绝对路径> -C <源目录所在父目录> <需要打包的源目录名称>
```

命令示例：
```powershell
PS D:\gitsrd\ems-wxj-version\ems-server> tar -czf D:\gitsrd\ems-wxj-version\ems-server\_temp\ems-server-src.tar.gz -C D:\gitsrd\ems-wxj-version\ems-server\_temp ems-server-src
```

tar 打包指定路径

Maven 工程配置阿里云镜像



```xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.caibh</groupId>
    <artifactId>order-analyzer</artifactId>
    <version>1.0.0</version>

    <name>order-analyzer</name>
    <description>快递订单分析助手</description>

    

    <repositories>
        <repository>
            <id>public</id>
            <name>AliYun public repository</name>
            <url>https://maven.aliyun.com/repository/public/</url>
            <releases>
                <enabled>true</enabled>
            </releases>
        </repository>
    </repositories>


    <pluginRepositories>
        <pluginRepository>
            <id>public</id>
            <name>AliYun public plugin repository</name>
            <url>https://maven.aliyun.com/repository/public/</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </pluginRepository>
    </pluginRepositories>

</project>
```