MySQL：锁的分类

行级锁

Record Lock

记录锁有S锁（共享锁/读锁）和X锁（排他锁/写锁）之分，加完S锁可以接着加S锁，加完X锁不能加X/S锁。

Gap Lock

间隙锁，间隙锁之间是兼容的，即两个事务可以同时持有包含共同间隙范围的间隙锁，并不存在互斥关系，因为间隙锁的目的是防止插入幻影记录而提出的。

Next-Key Lock

Next-Key Lock 称为临键锁，是 Record Lock + Gap Lock 的组合，锁定一个范围，并且锁定记录本身，如果一个事务获取了 X 型的 next-key lock，那么另外一个事务在获取相同范围的 X 型的 next-key lock 时，是会被阻塞的。

插入意向锁

要插入数据的时候要知道插入位置有没有间隙锁，如果有的话，插入操作就会发生阻塞，直到拥有间隙锁的那个事务提交为止（释放间隙锁的时刻），在此期间会生成一个插入意向锁，表明有事务想在某个区间插入新记录，但是现在处于等待状态。
插入意向锁名字虽然有意向锁，但是它并不是意向锁，它是一种特殊的间隙锁(锁一个点)，属于行级别锁。

表级锁

表锁

限制所有线程接下来的读写操作（包括本线程）

# 加锁
# 表级别的共享锁，也就是读锁；
lock tables 表名 read;
# 表级别的独占锁，也就是写锁；
lock tables 表名 write;
# 解除当前会话全部表锁
unlock tables

会话退出后当前会话的所有锁都会自动释放

元数据锁（MDL）

它的作用就是保证你在进行数据操作时表的结构不会变化，同时保证不会有多个线程修改表结构，我们不需要显示的使用 MDL，事务开始时自动上锁，事务结束自动解锁：

• 进行数据处理时加的是 MDL 读锁
• 进行表结构处理时加的是 MDL 写锁

申请 MDL 锁的操作会形成一个队列，队列中写锁获取优先级高于读锁，一旦出现 MDL 写锁等待，会阻塞后续该表所有数据处理操作。

意向锁

并不是真正意义上的加锁，而是告诉别的事务这里可能有什么类型的锁，对方知道后可以进行紧急避险，可以在不影响并发性的同时避免一些死锁的产生。
在InnoDB 中对行加共享锁/独占锁前需要在表级加一个对应的意向锁。

AUTO-INC 锁

表里的主键通常都会设置成自增的，这是通过对主键字段声明 AUTO_INCREMENT 属性实现的。
AUTO-INC 锁是特殊的表锁机制，锁不是再一个事务提交后才释放，而是再执行完插入语句后就会立即释放。
它的作用是保证获取递增的主键值时不会受别的事务干扰，MySQL 5.1.22开始这个锁变得更加轻量，在赋完值后就会自动解锁。

• 当 innodb_autoinc_lock_mode = 0，就采用 AUTO-INC 锁，语句执行结束后才释放锁；
• 当 innodb_autoinc_lock_mode = 2，就采用轻量级锁，申请自增主键后就释放锁，并不需要等语句执行后才释放。
• 当 innodb_autoinc_lock_mode = 1：
• • 普通 insert 语句，自增锁在申请之后就马上释放；
• • 类似 insert … select 这样的批量插入数据的语句，自增锁还是要等语句结束后才被释放；

如果使用轻量级自增锁的时候，binlog 的日志格式最好使用row，这样在 binlog 里面记录的是主库分配的自增值，到备库执行的时候，主库的自增值是什么，从库的自增值就是什么。
不然的话容易出现数据不一致，比如事务A将查询结果插入的时候事务B进行插入可能会将数据插入查询出的数据之间。

全局锁

锁住整个数据库，让整个数据库变得只读，全局锁主要应用于做全库逻辑备份，这样在备份数据库期间，不会因为数据或表结构的更新，而出现备份文件的数据与预期的不一样。

# 打开全局锁
flush tables with read lock
# 关闭全局锁
unlock tables

关闭当前会话时会自动解锁

存在问题：执行期间会造成业务停滞，生产环境比较致命
解决方案：如果数据库引擎支持可重复读的话可以创建read view进行拷贝，这样其它业务还可以正常进展。
备份数据库的工具是 mysqldump，在使用 mysqldump 时加上 –single-transaction 参数的时候，就会在备份数据库之前先开启事务。这种方法只适用于支持「可重复读隔离级别的事务」的存储引擎。