mysql的锁与事务

1. MySQL中的事物

  1、InnoDB事务原理

      1. 事务(Transaction)是数据库区别于文件系统的重要特性之一,事务会把数据库从一种一致性状态转换为另一种一致性状态。

      2. 在数据库提交时,可以确保要么所有修改都已保存,要么所有修改都不保存。

  2、事务的(ACID)特征

      1. 原子性(Atomicity):整个事务的所有操作要么全部提交成功,要么全部失败回滚(不会出现部分执行的情况)。

      2. 一致性(Consistency):几个并行执行的事务,其执行结果必须与按某一顺序串行执行的结果相一致。

      3. 隔离性(Isolation):事务的执行不受其他事务的干扰,事务执行的中间结果对其他事务必须是透明的。

      4. 持久性(Durability):  一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的,即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

  3、事务分类

    1 扁平事务

        1)扁平事务(Flat Transactions)是事务类型中最简单但使用最频繁的事务。

        2)在扁平事务中,所有的操作都处于同一层次,由BEGIN/START TRANSACTION开始事务,
             由COMMIT/ROLLBACK结束且都是原子的,要么都执行,要么都回滚。

    2 链事务

        1)链事务(Chained Transaction)是指一个事务由多个子事务链式组成。

        2)前一个子事务的提交操作和下一个子事务的开始操作合并成一个原子操作

        3)这样,在提交子事务时就可以释放不需要的数据对象,而不必等到整个事务完成后才释放。

        4)链事务中的回滚仅限于当前事务,相当于只能恢复到最近的一个保存节点,而带保存节点的扁平事务能回滚到任意正确的保存点。

    3 嵌套事务

        1)嵌套事务(Nested Transaction)是一个层次结构框架,由一个顶层事务(top-level transaction)控制着各个层次的事务。

        2)顶层事务之下嵌套的事务成为子事务(subtransaction),其控制着每一个局部的操作,子事务本身也可以是嵌套事务。

        3)因此,嵌套事务的层次结构可以看成是一颗树。

    4 分布式事务

        1)分布式事务(Distributed Transactions)通常是一个在分布式环境下运行的扁平事务,因此需要根据数据所在位置访问网络中不同节点的数据库资源。

        2)例如一个银行用户从招商银行的账户向工商银行的账户转账1000元,这里需要用到分布式事务,因为不能仅调用某一家银行的数据库就完成任务。

  4、事物隔离级别

    1 未提交读: 脏读(READ UNCOMMITTED) 

        1)事务2查询到的数据是事务1中修改但未提交的数据,但因为事务1回滚了数据

        2)所以事务2查询的数据是不正确的,因此出现了脏读的问题。

    2 提交读: 不可重复读(READ COMMITTED)

        注:一个事务从开始到提交之前对数据所做的改变对其它事务是不可见的,这样就解决在READ-UNCOMMITTED级别下的脏读问题。

        1)事务2执行update语句但未提交前,事务1的前两个select操作返回结果是相同的。

        2)但事务2执行commit操作后,事务1的第三个select操作就读取到事务2对数据的改变。

        3)导致与前两次select操作返回不同的数据,因此出现了不可重复读的问题。

    3 可重复读: 幻读(REPEATABLE READ):这是MySQL的默认事务隔离级别

        1)事务每开启一个实例,都会分配一个版本号给它,如果读取的数据行正在被其它事务执行DELETE或UPDATE操作(即该行上有排他锁)

        2)这时该事物的读取操作不会等待行上的锁释放,而是根据版本号去读取行的快照数据(记录在undo log中)

        3)这样,事务中的查询操作返回的都是同一版本下的数据,解决了不可重复读问题。

        4)虽然该隔离级别下解决了不可重复读问题,但理论上会导致另一个问题:幻读(Phantom Read)。

        5)一个事务在执行过程中,另一个事物对已有数据行的更改,MVCC机制可保障该事物读取到的原有数据行的内容相同

        6)但并不能阻止另一个事务插入新的数据行,这就会导致该事物中凭空多出数据行,像出现了幻读一样,这便是幻读问题。

    4 可串行读(SERIALIZABLE) 

        1)这是事务的最高隔离级别,通过强制事务排序,使之不可能相互冲突,就是在每个读的数据行加上共享锁来实现。

        2)在该隔离级别下,可以解决前面出现的脏读、不可重复读和幻读问题,但也会导致大量的超时和锁竞争现象,一般不推荐使用。

2. mysql中锁

  1、MyISAM和InnoDB支持的锁类型

      1. 相对其他数据库而言,MySQL的锁机制比较简单,其最显著的特点是不同的存储引擎支持不同的锁机制。

      2. MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking)。

      3. InnoDB存储引擎既支持行级锁(row-level locking),也支持表级锁,但默认情况下是采用行级锁。

  2、MySQL这3种锁的特性

    1)行级锁

        1. 行级锁分为共享锁和排它锁,行级锁是Mysql中锁定粒度最细的锁。

        2. InnoDB引擎支持行级锁和表级锁,只有在通过索引条件检索数据的时候,才使用行级锁,否就使用表级锁。

        3. 行级锁开销大,加锁慢,锁定粒度最小,发生锁冲突概率最低,并发度最高

        举例: 只根据主键进行查询,并且查询到数据,主键字段产生行锁。

#### 行锁
'''
client1中执行:
    select * from shop where id=1 for update;
clenet2中执行:
    select * from shop where id=2 for update;   # 可以正常放回数据
    select * from shop where id=1 for update;   # 阻塞
'''
# 可以看到:id是主键,当在client1上查询id=1的数据时候,在client2上查询id=2的数据没问题
# 但在client2上查询id=1的数据时阻塞,说明此时的锁时行锁。
# 当client1执行commit时,clinet2查询的id=1的命令立即返回数据。

    2)表级锁

        1. 表级锁分为表共享锁和表独占锁。

        2. 表级锁开销小,加锁快,锁定粒度大、发生锁冲突最高,并发度最低

        举例:根据非主键不含索引(name)进行查询,并且查询到数据,name字段产生表锁。

#### 表锁
# 可以看到,client1通过非索引的name字段查询到prod11的数据后,在client2查prod**的数据会阻塞,产生表锁。
'''
client1中执行:
    select * from shop where name="prod11" for update;
clenet2中执行:
    select * from shop where name="prod**" for update;
'''

    3)页级锁

        1. 页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。

        2. 表级锁速度快,但冲突多,行级冲突少,但速度慢。

        3. 所以取了折衷的页级,一次锁定相邻的一组记录,BDB支持页级锁。

        4. 开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。

    总结:

        1. 表级锁更适合于以查询为主,只有少量按索引条件更新数据的应用,如Web应用;

        2. 而行级锁则更适合于有大量按索引条件并发更新少量不同数据,同时又有并发查询的应用,如一些在线事务处理(OLTP)系统。

  3、锁分类

      1. 按操作划分:DML锁,DDL锁

      2. 按锁的粒度划分:表级锁、行级锁、页级锁

      3. 按锁级别划分:共享锁、排他锁

      4. 按加锁方式划分:自动锁、显示锁

      5. 按使用方式划分:乐观锁、悲观锁

  4、乐观锁悲观锁作用

      1. 在并发访问情况下,很有可能出现不可重复读等等读现象。

      2. 为了更好的应对高并发,封锁、时间戳、乐观并发控制(乐观锁)、
          悲观并发控制(悲观锁)都是并发控制采用的主要技术方式。

  5、悲观锁

      1. 悲观锁的实现,往往依靠数据库提供的锁机制

      2. MySQL会对查询结果集中每行数据都添加排他锁,其他线程对该记录的更新与删除操作都会阻塞,排他锁包含行锁、表锁。

      3. 申请前提:没有线程对该结果集中的任何行数据使用排他锁或共享锁,否则申请会阻塞。

      适用场景:悲观锁适合写入频繁的场景。

      注:

        首先我们需要set autocommit=0,即不允许自动提交
        用法:select * from tablename where id = 1 for update;

  6、乐观锁

      1. 在更新数据的时候需要比较程序中的库存量与数据库中的库存量是否相等,如果相等则进行更新。

      2. 反之程序重新获取库存量,再次进行比较,直到两个库存量的数值相等才进行数据更新。

  7、举例:对商品数量-1操作

    1)悲观锁实现方法

        1. 每次获取商品时,对该商品加排他锁。

        2. 也就是在用户A获取获取 id=1 的商品信息时对该行记录加锁,期间其他用户阻塞等待访问该记录。

#### 悲观锁实现加一操作代码
# 我们可以看到,首先通过begin开启一个事物,在获得shop信息和修改数据的整个过程中都对数据加锁,保证了数据的一致性。
'''
begin;
select id,name,stock as old_stock from shop  where id=1 for update;
update shop set stock=stock-1 where id=1 and stock=old_stock;
commit
'''

  

    2)乐观锁实现方法

        1. 每次获取商品时,不对该商品加锁。

        2. 在更新数据的时候需要比较程序中的库存量与数据库中的库存量是否相等,如果相等则进行更新

        3. 反之程序重新获取库存量,再次进行比较,直到两个库存量的数值相等才进行数据更新。

#### 乐观锁实现加一操作代码
# 我们可以看到,只有当对数量-1操作时才会加锁,只有当程序中值和数据库中的值相等时才正真执行。
'''
//不加锁
select id,name,stock where id=1;
//业务处理
begin;
update shop set stock=stock-1 where id=1 and stock=stock;
commit;
'''

  8、python适用乐观锁解决事物问题

      使用 django.db.transaction 模块解决MySQL 事物管理 问题   

      1. 在事务当前启动celery异步任务, 无法获取未提交的改动.

      2. 在使用transaction当中, Model.save()都不做commit .

      3. 因此如果在transaction当中设置异步任务,使用get()查询数据库,将看不到对象在事务当中的改变.

      4. 这也是实现”可重复读”的事务隔离级别,即同一个事务里面的多次查询都应该保持结果不变.

      5. Mysql在V5.1之前默认存储引擎是MyISAM;在此之后默认存储引擎是InnoDB

# with语句用法

from django.db import transaction

def viewfunc(request):
    # 这部分代码不在事务中,会被Django自动提交
    ...

    with transaction.atomic():
        # 这部分代码会在事务中执行
        ...
'''
from django.db import transaction

# 创建保存点
save_id = transaction.savepoint()  

# 回滚到保存点
transaction.savepoint_rollback(save_id)

# 提交从保存点到当前状态的所有数据库事务操作
transaction.savepoint_commit(save_id)
'''

  9、MySQL中 共享锁 和 排它锁 

    1)排它锁

        1. 排它锁又叫写锁,如果事务T对A加上排它锁,则其它事务都不能对A加任何类型的锁。获准排它锁的事务既能读数据,又能写数据。

        2.数据库的增删改操作默认都会加排他锁,而查询不会加任何锁。

        3. 用法 :  SELECT … FOR UPDATE

    2)共享锁(share lock)

        1. 共享锁又叫读锁,如果事务T对A加上共享锁,则其它事务只能对A再加共享锁,不能加其它锁。

        2. 获准共享锁的事务只能读数据,不能写数据。

        3. 用法: SELECT … LOCK IN SHARE MODE;

posted @ 2020-03-11 21:14  darkly  阅读(324)  评论(1编辑  收藏  举报