mysql有哪些锁，理解各种表锁和行锁

全局锁

主要用于数据库的备份，但会使得备份期间不能有任何事务插入删除更新数据，这很影响实际业务。所以通常不用这个全局锁来完成数据库的备份。假设数据库的存储引擎支持可重复读，那么常见的方法是通过MVCC来实现的，也就是备份事务开始时候创建一个read view，然后根据这个read view来备份，这样不影响其他事务的更新。

表级锁

表锁

基本不用，太拉了。共享锁（读锁）和独占锁（写锁），一个事务申请了表锁，不仅限制别的事务读写，还会限制自己的读写。

元数据锁（MDL）

不需要显式的加MDL，会自动加：

对一张表进行 CRUD 操作时，加的是 MDL 读锁；
对一张表做结构变更操作的时候，加的是 MDL 写锁；
主要目的是防止
用户对表执行 CRUD 操作时，防止其他线程对这个表结构做了变更。

当有线程在执行 select 语句（加 MDL 读锁）的期间，如果有其他线程要更改该表的结构（申请 MDL 写锁），那么将会被阻塞，直到执行完 select 语句（释放 MDL 读锁）。

反之，当有线程对表结构进行变更（加 MDL 写锁）的期间，如果有其他线程执行了 CRUD 操作（申请 MDL 读锁），那么就会被阻塞，直到表结构变更完成（释放 MDL 写锁）。
MDL 是在事务提交后才会释放，这意味着事务执行期间，MDL 是一直持有的。这也就意味着假设A事务读表，B事务可以读，但C事务想改就不行会被阻塞，此后DEF事务想读都不行了，因为C要写而且排在他们前面。数据库线程会很快爆满。

意向锁

意向锁是指有事务想修改或者读取表的某一部分，会先加个意向锁然后再加行锁。实际上用意向锁就是告诉后续有事务想申请表级独占锁（X，写锁）或者共享锁（S，读锁），不行，这里有人在用。当然了，行锁和表锁还是满足读读共享、读写互斥、写写互斥的。
在这里插入图片描述

AUTO-INC锁

表里的主键通常是自增的。插入时候不显式赋值，主键也能完成自增，靠的就是这个AUTO-INC锁。锁的释放不是事务终止才释放的，是插入完成后就释放。但这样不同事务在插入数据时候会相互阻塞。所以不太合适。因此innoDB引入了一种轻量级锁innodb_autoinc_lock_mode，在插入时候，自增字段赋值结束后就释放锁，而不用等到语句整个插入完。
在这里插入图片描述
当 innodb_autoinc_lock_mode = 2 是性能最高的方式，但是当搭配 binlog 的日志格式是 statement 一起使用的时候，在「主从复制的场景」中会发生数据不一致的问题。看下面例子。

session B 先插入了两个记录，(1,1,1)、(2,2,2)；
然后，session A 来申请自增 id 得到 id=3，插入了（3,5,5)；
之后，session B 继续执行，插入两条记录 (4,3,3)、 (5,4,4)。
可以看到，session B 的 insert 语句，生成的 id 不连续。

当「主库」发生了这种情况，binlog 面对 t2 表的更新只会记录这两个 session 的 insert 语句，如果 binlog_format=statement，记录的语句就是原始语句。记录的顺序要么先记 session A 的 insert 语句，要么先记 session B 的 insert 语句。

但不论是哪一种，这个 binlog 拿去「从库」执行，这时从库是按「顺序」执行语句的，只有当执行完一条 SQL 语句后，才会执行下一条 SQL。因此，在从库上「不会」发生像主库那样两个 session 「同时」执行向表 t2 中插入数据的场景。所以，在备库上执行了 session B 的 insert 语句，生成的结果里面，id 都是连续的。这时，主从库就发生了数据不一致。

要解决这问题，binlog 日志格式要设置为 row，这样在 binlog 里面记录的是主库分配的自增值，到备库执行的时候，主库的自增值是什么，从库的自增值就是什么。

所以，当 innodb_autoinc_lock_mode = 2 时，并且 binlog_format = row，既能提升并发性，又不会出现数据一致性问题。

行级锁

innoDB独有的额，MyISAM没有
在这里插入图片描述

Record Lock

记录锁、行锁，也就是仅仅把一条记录锁上。主要是对删除和修改的限制。

当一个事务对一条记录加了 S 型记录锁后，其他事务也可以继续对该记录加 S 型记录锁（S 型与 S 锁兼容），但是不可以对该记录加 X型记录锁（S 型与 X 锁不兼容）;
当一个事务对一条记录加了 X 型记录锁后，其他事务既不可以对该记录加 S 型记录锁（S 型与 X
锁不兼容），也不可以对该记录加 X 型记录锁（X 型与 X 锁不兼容）。