MySQL实战45讲学习笔记:第三讲

1、隔离性与隔离级别

一、事务的特性

原子性mysql

一致性sql

隔离性数据库

持久性安全

二、不一样事务隔离级别的区别

读未提交:别人改数据的事务还没有提交,我在个人事务中也能读到。
读已提交:别人改数据的事务已经提交,我在个人事务中才能读到。
可重复读:别人改数据的事务已经提交,我在个人事务中也不去读。
串行:个人事务还没有提交,别人就别想改数据。
这4种隔离级别,并行性能依次下降,安全性依次提升。bash

三、读提交”和“可重复读”

 假设数据表T中只有一列,期中一行的值为1,下面是按照时间顺序执行两个事物的行为并发

mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);

实际测试代码以下:性能

mysql> create table T(c int) engine=InnoDB;
Query OK, 0 rows affected (0.01 sec)

mysql> insert into T(c) values(1);
Query OK, 1 row affected (0.01 sec)

 咱们来看看在不一样隔离级别下,事务A会有哪些不一样的返回结果,也就是图里面V一、V二、V3的返回值分别是什么?学习

 

实际测试代码以下

查看隔离级别:测试

mysql> show variables like 'transaction_isolation';
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+

事务A实际测试代码:spa

mysql> use test;
Database changed
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from T;
+------+
| c    |
+------+
|    1 |
+------+
1 row in set (0.00 sec)

mysql> select * from T;
+------+
| c    |
+------+
|    1 |
+------+
1 row in set (0.00 sec)

mysql> mysql> select * from T;
+------+
| c    |
+------+
|    1 |
+------+
1 row in set (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from T;
+------+
| c    |
+------+
|    2 |
+------+
1 row in set (0.00 sec)

事务B实际测试代码:

mysql> use test;
Database changed
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from T;
+------+
| c    |
+------+
|    1 |
+------+
1 row in set (0.00 sec)

mysql> update T set c=5 where id=1;
ERROR 1054 (42S22): Unknown column 'id' in 'where clause'
mysql> update T set c=2 ;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

四、隔离级别的配置方法

Oracle 数据库的默认隔离级别其实就是“读提交”,所以对对于一些从 Oracle 迁移到 MySQL 的应用,为保证数据库隔离级别的一致,你必定要记得将 MySQL 的隔离级别
设置为“读提交”

mysql> show variables like 'transaction_isolation';

+-----------------------+----------------+

| Variable_name | Value |

+-----------------------+----------------+

| transaction_isolation | READ-COMMITTED |

+-----------------------+----------------+

实际测试代码以下:

mysql> show variables like 'transaction_isolation';
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.01 sec)

五、可重复读的场景

假设你在管理一个个银行帐户表,

一、一个表存了每月月底的余额,一个表存了帐单明细,
二、这时候你要作数据校对,也就是判断上个月的余额和当前余额的差额,是否与本月的帐单明细一直
三、你必定但愿在校对的过程当中,即便有用户发生了一笔新的交易,也不影响你的校队结果

这时候"可重复读"隔离级别就很方便,事务启动时的视图能够认为是静态的,不受其余食物更新的影响

2、事务隔离的实现

一、事务隔离的实现

假设一个值1被按顺序改为二、三、4,在回滚日志里面就会有相似下面的记录

每条记录在更新的时候都会同时记录一条回滚操做。同一条记录在系统中能够存在多个版本,这就是数据库的多版本并发控制(MVCC)

对于read-view A ,要的到1就必须将当前值依次执行途中全部回滚操做的到

二、事务隔离的几个为何?

一、回滚日志何时删除?

系统会判断当没有事务须要用到这些回滚日志的时候,回滚日志会被删除

二、何时不须要了?

当系统里没有比这个回滚日志更早的read-view的时候。

三、为何尽可能不要使用长事务

长事务意味着系统里面会存在很老的事务视图,在这个事务提交以前,回滚记录都要保留,这会致使大量占用存储空间。除此以外,长事务还占用锁资源,可能会拖垮库。

3、事务启动方式

一、启动方式

 其实不少时候业务开发同窗并非有意使用长事务,挺长是因为误用所致,MySQL 的事务启动方式有如下几种

方式一

显式启动事务语句,begin或者start transaction,提交commit,回滚rollback;

方式一

set autocommit=0,该命令会把这个线程的自动提交关掉。这样只要执行一个select语句,事务就启动,

并不会自动提交,直到主动执行commit或rollback或断开链接

二、建议使用方式一

若是考虑多一次交互问题,可使用commit work and chain语法。在autocommit=1的状况下用begin显式启动事务,

若是执行commit则提交事务。若是执行commit work and chain则提交事务并自动启动下一个事务。

三、如何查询长事务

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

实际测试代码以下:

mysql> select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60\G;
*************************** 1. row ***************************
                    trx_id: 1806
                 trx_state: RUNNING
               trx_started: 2019-10-15 03:34:50
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 2
       trx_mysql_thread_id: 6
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 1
          trx_lock_structs: 2
     trx_lock_memory_bytes: 1136
           trx_rows_locked: 1
         trx_rows_modified: 0
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
*************************** 2. row ***************************
                    trx_id: 421762016601952
                 trx_state: RUNNING
               trx_started: 2019-10-15 03:34:11
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 2
       trx_mysql_thread_id: 7
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 1
          trx_lock_structs: 2
     trx_lock_memory_bytes: 1136
           trx_rows_locked: 1
         trx_rows_modified: 0
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
2 rows in set (0.00 sec)

ERROR: 
No query specified

4、思考题(同窗们的经典留言)

一、Gavin同窗的形象实例

下面是个人自问自答,也是个人学习笔记,问下斌哥,这样理解准确吗?
在可重复读的隔离级别下,如何理解**当系统里没有比这个回滚日志更早的 read-view 的时候**,这个回滚日志就会被删除?

这也是**尽可能不要使用长事务**的主要缘由。



好比,在某个时刻(今天上午9:00)开启了一个事务A(对于可重复读隔离级别,此时一个视图read-view A也建立了),这是一个很长的事务……

事务A在今天上午9:20的时候,查询了一个记录R1的一个字段f1的值为1……
今天上午9:25的时候,一个事务B(随之而来的read-view B)也被开启了,它更新了R1.f1的值为2(同时也建立了一个由2到1的回滚日志),这是一个短事务,事务随后就被commit了。
今天上午9:30的时候,一个事务C(随之而来的read-view C)也被开启了,它更新了R1.f1的值为3(同时也建立了一个由3到2的回滚日志),这是一个短事务,事务随后就被commit了。
……
到了下午3:00了,长事务A尚未commit,为了保证事务在执行期间看到的数据在先后必须是一致的,那些老的事务视图、回滚日志就必须存在了,这就占用了大量的存储空间。
源于此,咱们应该尽可能不要使用长事务。

二、MySQL中undo的内容会被记录到redo中吗?(来自于* 晓 *同窗)

好比一个事务在执行到一半的时候实例崩溃了,在恢复的时候是否是先恢复redo,再根据redo构造undo回滚宕机前没有提交的事务呢?

做者回复: 对的,是你说的这个流程

三、脏读、幻读、不可重复读(来自于William同窗)

一、脏读:

    当数据库中一个事务A正在修改一个数据可是还未提交或者回滚,
    另外一个事务B 来读取了修改后的内容而且使用了,
    以后事务A提交了,此时就引发了脏读。 
   
    此状况仅会发生在: 读未提交的的隔离级别.

 二、不可重复读:


    在一个事务A中屡次操做数据,在事务操做过程当中(未最终提交),
    事务B也才作了处理,而且该值发生了改变,这时候就会致使A在事务操做
    的时候,发现数据与第一次不同了。 就是不可重复读。
  
    此状况仅会发生在:读未提交、读提交的隔离级别.

三、幻读

    一个事务按相同的查询条件从新读取之前检索过的数据,
    却发现其余事务插入了知足其查询条件的新数据,这种现象就称为幻读。
    
    幻读是指当事务不是独立执行时发生的一种现象,例如第一个事务对一个表中的数据进行了修改,好比这种修改涉及到表中的“所有数据行”。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入“一行新数据”。那么,之后就会发生操做第一个事务的用户发现表中还存在没有修改的数据行,就好象发生了幻觉同样.
    通常解决幻读的方法是增长范围锁RangeS,锁定检索范围为只读,这样就避免了幻读。
    
    此状况会回发生在:读未提交、读提交、可重复读的隔离级别.

四、形象总结(来自null同窗)

视图理解为数据副本,每次建立视图时,将当前『已持久化的数据』建立副本,后续直接从副本读取,从而达到数据隔离效果。

一、存在视图的 2 种隔离级别:

1. 读提交
2. 可重复读

读提交:在每一条 SQL 开始执行时建立视图,隔离做用域仅限该条 SQL 语句。
可重复读:事务启动时建立视图,所以,在事务任意时刻,对记录读取的值都是同样的。

二、其余 2 种无视图的隔离级别:

1. 读未提交2. 串行化读未提交:直接返回记录最新值。串行化:经过读写锁来避免并行访问。读-读:容许并发执行读-写:只能串行写-写:只能串行

相关文章
相关标签/搜索