文章目录
行级锁
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 时,是会被阻塞的。
插入意向锁
要插入数据的时候要知道插入位置有没有间隙锁,如果有的话,插入操作就会发生阻塞,直到拥有间隙锁的那个事务提交为止(释放间隙锁的时刻),在此期间会生成一个插入意向锁,表明有事务想在某个区间插入新记录,但是现在处于等待状态。
插入意向锁名字虽然有意向锁,但是它并不是意向锁,它是一种特殊的间隙锁(锁一个点),属于行级别锁。
表级锁
表锁
限制所有线程接下来的读写操作(包括本线程)
bash
# 加锁
# 表级别的共享锁,也就是读锁;
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进行插入可能会将数据插入查询出的数据之间。
全局锁
锁住整个数据库,让整个数据库变得只读,全局锁主要应用于做全库逻辑备份,这样在备份数据库期间,不会因为数据或表结构的更新,而出现备份文件的数据与预期的不一样。
bash
# 打开全局锁
flush tables with read lock
# 关闭全局锁
unlock tables
关闭当前会话时会自动解锁
存在问题:执行期间会造成业务停滞,生产环境比较致命
解决方案:如果数据库引擎支持可重复读的话可以创建read view进行拷贝,这样其它业务还可以正常进展。
备份数据库的工具是 mysqldump,在使用 mysqldump 时加上 --single-transaction 参数的时候,就会在备份数据库之前先开启事务。这种方法只适用于支持「可重复读隔离级别的事务」的存储引擎。