MySQL锁
MySQL表级锁的锁模式
|
请求锁模式
是否兼容
当前锁模式
|
None | 读锁 | 写锁 |
| 读锁 | 是 | 是 | 否 |
| 写锁 | 是 | 否 | 否 |
相对于其他的数据库而言，MySQL的锁机制比较简单，最显著的特点就是不同的存储引擎支持不同的锁机制。根据不同的存储引擎，MySQL中锁的特性可以大致归纳如下：
开销、加锁速度、死锁、粒度、并发性能
- 表锁：开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低
- 行锁：开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高
- 页锁：开销和加锁速度介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般
| 行锁 | 表锁 | 页锁 | |
| MyISAM | √ | ||
| BDB | √ | √ | |
| InnoDB | √ | √ |
1、锁的分类
1.1从对数据操作的类型来分
读锁（共享锁）:针对同一份数据，多个读操作可以同时进行而不会互相影响。
结论1：
--如果某一个会话 对A表加了read锁，则 该会话 可以对A表进行读操作、不能进行写操作； 且 该会话不能对其他表进行读、写操作。
--即如果给A表加了读锁，则当前会话只能对A表进行读操作。
结论2：
会话0给A表加了锁；其他会话的操作：a.可以对其他表（A表以外的表）进行读、写操作
b.对A表：读-可以； 写-需要等待释放锁。、
某回话给某个表加了读锁，所有的回话都能对该表进行读操作，不能进行写操作，除非该会话释放读锁。
写锁（排它锁）:当前写操作没有完成前，它会阻断其他写锁和读锁。
当前会话（会话0） 可以对加了写锁的表 进行任何操作（增删改查）；但是不能 操作（增删改查）其他表
其他会话：对会话0中加写锁的表 可以进行增删改查的前提是：等待会话0释放写锁
2.2从锁粒度划分。
一般分为：行锁、表锁、库锁
（1）行锁：访问数据库的时候，锁定整个行数据，防止并发错误。 如InnoDB存储引擎使用行锁
（2）表锁：访问数据库的时候，锁定整个表数据，防止并发错误。 如MyISAM存储引擎使用表锁
行锁 和 表锁 的区别：
- 表锁： 开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突概率高，并发度最低
- 行锁： 开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高
2. 3 补充 悲观锁 和 乐观锁
（1）悲观锁：顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
（2）乐观锁： 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
（3）悲观锁 和 乐观锁的区别：
- 乐观锁在不发生取锁失败的情况下开销比悲观锁小，但是一旦发生失败回滚开销则比较大，因此适合用在取锁失败概率比较小的场景，可以提升系统并发性能
- 乐观锁还适用于一些比较特殊的场景，例如在业务操作过程中无法和数据库保持连接等悲观锁无法适用的地方
小结：
MySQL表级锁的锁模式
MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，
在执行更新操作（DML）前，会自动给涉及的表加写锁。
所以对MyISAM表进行操作，会有以下情况：
a、对MyISAM表的读操作（加读锁），不会阻塞其他进程（会话）对同一表的读请求，
但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其它进程的写操作。
b、对MyISAM表的写操作（加写锁），会阻塞其他进程（会话）对同一表的读和写操作，
只有当写锁释放后，才会执行其它进程的读写操作。
在Innodb引擎中既支持行锁也支持表锁，那么什么时候会锁住整张表，什么时候或只锁住一行呢？
InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。
行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁。行级锁的缺点是：由于需要请求大量的锁资源，所以速度慢，内存消耗大。
