mysql在Spring隔离 mysql 隔离机制

转载

killads 2023-11-28 09:20:11

文章标签 mysql在Spring隔离数据库运维客户端数据 文章分类 MySQL 数据库

一：MySQL锁

二：MySQL事务

三：MySQL隔离级别

四：MVCC

1.1为什么要有锁？

因为数据库要解决并发控制问题。在同一时刻，可能会有多个客户端对某张表的某条数据或某些数据进行操作，比如有的在读取该行数据，其他的尝试去删除它。为了保证数据的一致性，数据库就要对这种并发操作进行控制，因此就有了锁的概念。

1.2锁的分类

1.2.1按对数据的操作类型

LOCK TABLES tb_namelock_type{READ|WRITE};

UNLOCKTABLES ;

读锁（共享锁）：针对同一块数据，多个读操作可以同时进行而不会互相影响。

写锁（排它锁）：当前写操作没有完成前，它会阻断其他写锁和读锁。

示例1：读锁

mysql在Spring隔离 mysql 隔离机制_数据库

mysql在Spring隔离 mysql 隔离机制_数据_02

mysql在Spring隔离 mysql 隔离机制_数据库_03

mysql在Spring隔离 mysql 隔离机制_数据库_04

示例2：写锁

mysql在Spring隔离 mysql 隔离机制_客户端_06

mysql在Spring隔离 mysql 隔离机制_数据库_07

mysql在Spring隔离 mysql 隔离机制_运维_08

1.2.2锁的粒度：MySQL服务器仅支持表级别的所，行所需要存储引擎完成

表锁：管理锁的开销最小，同时允许的并发量也最小的锁机制。MyIsam存储引擎使用的锁机制。当要写入数据时，把整个表都锁上，此时其他读、写动作一律等待。在MySql中，除了MyIsam存储引擎使用这种锁策略外，MySql本身也使用表锁来执行某些特定动作，比如alter table.

行锁：可以支持最大并发的锁策略。InnoDB存储引擎采用这种策略

2.1 ACID

原子性（Autmic）：事务所引起的数据库操作，要么都完成，要么都不执行

一致性（Consistency）：完成之前和完成之后是一样的（两个帐户的钱，转账之前和之后的总和是一样的）

隔离性（Isolation）：一个事务的执行不能影响另一个事务的执行

持久性（Durability）：一旦事务成功完成，系统必须保证任何故障都不能引起事务的不一致性。

2.2事务的状态

2.3保存点（SAVEPOINT）

一个很大的事务，这个事务有100个操作，执行到80个的时候发现第75个错了，怎么办？

撤销？？---->80个都撤销了--->不好

这样就引出保存点了，每10个做一次保存点

回滚保存点：ROLLBACK TO sid

示例：

mysql在Spring隔离 mysql 隔离机制_数据_11

mysql在Spring隔离 mysql 隔离机制_数据库_12

3.1事务的隔离级别

READ-UNCOMMITTED：读未提交别人一操作，立马就能看见(最低的隔离级别)

READ-COMMITTED：读提交别人提交了，才能看见

REPEATABLE-READ：可重读

（不管别的事务是否提交，我的事务之内看到的依然是一样的，例如A事务执行了UPDATE操

作，B事务执行SELECT操作，在A执行前和后,B执行的结果都一样）

SERIALIZABLE：可串行化

查看当前数据库的隔离级别：

SHOW GLOBAL VARIABLES LIKE '%ISO%';

SELECT @@TX_ISOLATION;

mysql在Spring隔离 mysql 隔离机制_数据_13

mysql在Spring隔离 mysql 隔离机制_运维_14

3.2事务隔离级别对事务的影响

3.2.1READ-UNCOMMITTED示例

【客户端1】

【客户端2】

【客户端1】

【客户端2】

总结：客户端2在一个事务内，两次读取的数据不一样，产生了幻读

3.2.2READ-COMMITTED

【客户端1】

【客户端2】

【客户端1】

【客户端2】

总结：客户端1未执行提交之前，客户端2看不到更新后的数据，客户端1执行提交之后，客户端2看到了更新以后的数据，客户端2在一个事务内，执行两次查询仍然看到了不同的结果，依然存在幻读的问题

3.2.3REPEATABLE-READ

【客户端1】

【客户端2】

【客户端1】

【客户端2】

总结：客户端2在提交前和提交后看到的数据依然不一样，产生了幻读

3.2.4SERIALIZABLE

【客户端1】

【客户端2】

【客户端1】

【客户端2】

总结：虽然不存在数据幻读的问题，但是执行效率非常低

以下内容来自于：

4.1相关概念

redo log

redo log就是保存执行的SQL语句到一个指定的Log文件，当Mysql执行recovery时重新执行redo log记录的SQL操作即可。当客户端执行每条SQL（更新语句）时，redo log会被首先写入log buffer；当客户端执行COMMIT命令时，log buffer中的内容会被视情况刷新到磁盘。redo log在磁盘上作为一个独立的文件存在，即Innodb的log文件。

undo log

与redo log相反，undo log是为回滚而用，具体内容就是copy事务前的数据库内容（行）到undo buffer，在适合的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样，也是环形缓冲，但当缓冲满的时候，undo buffer中的内容会也会被刷新到磁盘；与redo log不同的是，磁盘上不存在单独的undo log文件，所有的undo log均存放在主ibd数据文件中（表空间），即使客户端设置了每表一个数据文件也是如此。

rollback segment

回滚段这个概念来自Oracle的事物模型，在Innodb中，undo log被划分为多个段，具体某行的undo log就保存在某个段中，称为回滚段。可以认为undo log和回滚段是同一意思。

4.2数据的更新过程

初始数据：假设这是刚刚INSERT的数据，可以认为隐含ID为1，其它两个值为NULL