1.2 并发控制

无论何时,只要有多个查询需要在同一时刻修改数据,就会产生并发控制的问题。

MySQL提供锁来防止数据损坏,但是这种方案并不支持并发处理。

1.2.1 读写锁

   共享锁(Shared),简写为 S 锁,又称读锁。是共享的,或者说是相互不阻塞的。多个客户在同一时刻可以同时读取同一个资源,而互不干扰。

     排它锁(Exclusive),简写为 X 锁,又称写锁。是排他的,也就是说一个写锁会阻塞其他的写锁和读锁,这是出于安全策略的考虑,只有这样,才能确保在给定的时间里,只有一个用户能执行写入,并防止其他用户读取正在写入的同一资源。    

  有以下两个规定:

  • 一个事务对数据对象 A 加了 X 锁,就可以对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。
  • 一个事务对数据对象 A 加了 S 锁,可以对 A 进行读取操作,但是不能进行更新操作。加锁期间其它事务能对 A 加 S 锁,但是不能加 X 锁。

1.2.2 锁粒度

  MySQL 中提供了两种封锁粒度:行级锁以及表级锁。

  应该尽量只锁定需要修改的那部分数据,而不是所有的资源。锁定的数据量越少,发生锁争用的可能就越小,系统的并发程度就越高。

  但是加锁需要消耗资源,锁的各种操作(包括获取锁、释放锁、以及检查锁状态)都会增加系统开销。因此封锁粒度越小,系统开销就越大。

  在选择封锁粒度时,需要在锁开销和并发程度之间做一个权衡。

  1. 表锁(table lock)是MySQL中最基本的锁策略,并且是开销最小的策略。它会锁定整张表。一个用户在对表进行写操作(插入、删除、更新等)前,需要先获得写锁,这会阻塞其他用户对该表的所有读写操作。只有没有写锁时,其他读取的用户才能获得读锁,读锁之间是不相互阻塞的。

  2. 行级锁(row lock)可以最大程度地支持并发处理(同时也带来了最大的锁开销)。在InnoDB和XtraDB,以及其他一些存储引擎中实现了行级锁。行级锁只在存储引擎层实现,而MySQL服务器层没有实现。服务器层完全不了解存储引擎中的锁实现。

1.2.3 MySQL 隐式与显示锁定

MySQL 的 InnoDB 存储引擎采用两段锁协议。在事物执行的过程中,随时都可以执行锁定,锁只有在执行COMMIT或者ROLLBACK的时候才会释放。InnoDB会根据隔离级别在需要的时候自动加锁,并且所有的锁都是在同一时刻被释放,这被称为隐式锁定。之前描述的锁定都是隐式锁定

InnoDB 也可以使用特定的语句进行显示锁定:

SELECT ... LOCK In SHARE MODE;
SELECT ... FOR UPDATE;
原文地址:https://www.cnblogs.com/xlzfdddd/p/10094306.html