mysql的封锁机制以及读锁和写锁的区别

转载自 ：https://blog.csdn.net/youcijibi/article/details/78142767

我们在开发中也许都有感受到，数据库的并发操作会带来许多问题，比如丢失更新、不可重复读、读脏数据（幽灵数据）等等，常见的比如自动售票系统，站点1、2同时读出剩余的票数n张，站点1售出一张票，并将n-1写入数据库，站点2也售出一张票并将n-1写入数据库，但是我们都知道，应剩余n-2张票，这就是典型的丢失数据更新的实例。为避免该类问题的产生，我们采用了封锁机制，简单点就是当一个线程要对数据库进行相关操作时，先给数据库加上适当的锁，以此来避免其他线程对数据库进行操作而带来的干扰。
并发操作之所以产生错误，是因为不同线程并发执行事务互相干扰造成的。所以我们要对事务的并发操作进行控制，即并发控制。一般DBMS进行并发控制的方法是封锁机制和事务机制。
封锁就是对数据表、数据行等操作之前，先向系统请求对其加锁，说通俗点就是操作之前先声明权限。
封锁的周期（环节）：申请加锁、获得锁权限、释放锁权限
最基本的封锁类型有两种：排它锁（Exclusive Locks，X锁）和共享锁（Share Locks，S锁）。

• 排它锁也称独占锁、写锁或X锁，若sessionA获得某数据表的排他锁权限，那么sessionA只能对该表进行读取或修改，其他session既不能读取也不能修改该表，更不能对该表加任何类型的锁，直到sessionA释放排它锁权限。加锁方式：lock tables tablename write；操作如下：
  sessionA:
  
  sessionB：
  
  从上图操作可以看出sessionA获得ha表排它锁权限以后sessionB执行访问ha表操作以后并没用显示ha数据而是在等待sessionA释放锁权限。

• 共享锁也称读锁或S锁，若sessionA获得某数据表的共享锁权限，那么任何session（包括sessionA）只能对该表进行读取，不能修改该表，sessionA可以继续对该数据表加X锁，其他session可以对该数据表继续加S锁但不能加X锁，直到sessionA释放共享锁权限。加锁方式：set tables tablename read；操作如下：
  sessionA：
  
  sessionB：
  
  从上图操作可以看出，sessionA获得ha表共享锁权限以后，sessionA和sessionB都可以访问ha表，但是当sessionA想更改ha表时直接报错（ERROR 1099 (HY000): Table ‘ha’ was locked with a READ lock and can’t be updated ha表有一个共享锁不能被修改），sessionB更改ha表时并没有显示修改成功，而是在等待sessionA释放共享锁权限。

• 注意，在sessionA同时获得某数据表的S和X锁权限时，sessionA只能select该数据表，其他session将不能对该表进行任何操作，包括select、update、drop、delete、lock等等，直到sessionA释放相关锁权限。

表锁的加锁/解锁方式

MyISAM 在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,在执行更新操作 (UPDATE、DELETE、INSERT 等)前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。

如果用户想要显示的加锁可以使用以下命令：

锁定表：LOCK TABLES tbl_name {READ | WRITE},[ tbl_name {READ | WRITE},…] 
 
解锁表：UNLOCK TABLES 
1
2
3

在用 LOCK TABLES 给表显式加表锁时,必须同时取得所有涉及到表的锁。

在执行 LOCK TABLES 后，只能访问显式加锁的这些表，不能访问未加锁的表;

如果加的是读锁，那么只能执行查询操作，而不能执行更新操作。

在自动加锁的情况下也基本如此，MyISAM 总是一次获得 SQL 语句所需要的全部锁。这也正是 MyISAM 表不会出现死锁(Deadlock Free)的原因。