MySQL并发控制整理

根据控制的不同层次，MySQL的并发控制可以分为：

• 服务器层
• 存储引擎层

实现并发控制的方法策略：锁机制

• 共享锁（shared lock）<======> 读锁（read lock）
• 排它锁（exclusive lock） <======> 写锁（write lock）

如何选择适合的锁？锁策略

• 锁的粒度越小，系统的并发性越高
• 所得操作越多，系统的开销越大

  所以所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡。

MySQL中锁策略类型

MySQL不同的存储引擎中用到的锁策略基本有两种。一种是表级锁，另一种是行级锁。

• 表锁，一种开销最小的锁策略。

  一个用户对表进行写操作时，需要先获得写锁，这是其他用户读该表进行的读写操作都会进行阻塞。只有当前写操作被释放之后，其他人才能活的读锁。当当前表有读锁时，其他人也可以继续获得读锁。读锁是共享性的不同的读锁之间是互相不阻塞的。
  另外，写锁的优先级高于读锁。所以当有多个锁请求存在是，读锁的请求会被优先插入到锁队列的前边。

• 行锁，最大程度支持并发处理，同时也是锁开销最大的锁策略。

  顾名思义，行级锁只在将要修改的记录行上进行锁操作，对其他的行的操作没有影响。

尽管我们一般提到的锁，都处于存储引擎这一层，但是MySQL本身在某些情况下，也会对锁策略进行控制。比如表的alter table操作，会对表本身使用表锁，而直接忽略存储引擎的锁机制。

MySQL中死锁问题解决方法

死锁，即两个或者多个事务在同一资源上相互占用，并请求占用对方已经占用的资源的情况。

既然有锁存在，当然就会有死锁的情况发生。那么MySQL中是如何处理死锁问题的呢？
死锁的通常解决方案有两种，即：

• 死锁检测机制
• 超时机制

InnoDB存储引擎在检测到有死锁发生的处理方法是，将当前持有最少的行级锁的事务进行回滚。待打破死锁后，重新执行因为死锁而回滚的事务。