MySql锁机制

MYSQL共有几种锁机制?

两种

• 共享锁(读锁):其他事务可以读,但不可以写
• 排它锁(写锁):其他事务不可以读也不可以写

MYSQL按锁粒度共分几种,有什么特点?

由小到大分三种

• 行锁:开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
• 表锁:开销小，加锁快；不会出现死锁；由于每次都是锁整张表,会造成查询这张表其他数据的事务都处于等待,所以并发量最小
• 页锁:开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

MYSQL不同引擎各支持什么锁粒度?默认是什么?

MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking）
BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁
InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。
默认情况下，表锁和行锁都是自动获得的， 不需要额外的命令。
InnoDB行锁是通过给索引上的索引项加锁来实现的，InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！

MyISAM 表锁和InnoDB的锁机制

• MyISAM:
  表共享读锁 （Table Read Lock）：不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；
  表独占写锁 （Table Write Lock）：会阻塞其他用户对同一表的读和写操作；
• InnoDB
  共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
  排他锁（X）：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。

InnoDB的加锁方式

共享锁:select … lock in share mode
排他锁:select … for update
select *** for update 的使用场景：为了让自己查到的数据确保是最新数据，并且查到后的数据只允许自己来修改的时候，需要用到 for update 子句。
select *** lock in share mode 使用场景：为了确保自己查到的数据没有被其他的事务正在修改，也就是说确保查到的数据是最新的数据，并且不允许其他人来修改数据。但是自己不一定能够修改数据，因为有可能其他的事务也对这些数据 使用了 in share mode 的方式上了 S 锁。

如何避免死锁?

MyISAM:在自动加锁的情况下，MyISAM 总是一次获得 SQL 语句所需要的全部锁，所以 MyISAM 表不会出现死锁。
InnoDB:

• 尽量使用较低的隔离级别
• 对查询到的记录集进行修改操作时一次获取到足够级别的锁,在修改数据时直接使用排它锁,而不是查询时用共享锁,修改时再加上排它锁
• 由于mysq的行锁是针对索引加锁,所以要精心设计索引
• 尽量使用=确定条件,避免间隙锁(是在范围查询时给范围内不存在的数据加锁的一种机制)影响并发
• 不要申请超过需要的锁机别
• 对于特定事物,可以使用表锁提高速度,减少死锁可能

乐观锁和悲观锁是什么?

其实是一种思想,并不是具体的方式,而是由这两种思想延伸出不同的加锁机制
乐观锁:就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
悲观锁:就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。