做网站第三方,wordpress 论坛 整合,找关键词,wordpress 取消做这MySQL之锁 锁是计算机在执行多线程或线程时用于并发访问同一共享资源时的同步机制#xff0c;MySQL中的锁是在服务器层或者存储引擎层实现的#xff0c;保证了数据访问的一致性与有效性 MySQL锁可以按模式分类为#xff1a;乐观锁与悲观锁。 按粒度分可以分为全局锁、表级锁…MySQL之锁 锁是计算机在执行多线程或线程时用于并发访问同一共享资源时的同步机制MySQL中的锁是在服务器层或者存储引擎层实现的保证了数据访问的一致性与有效性 MySQL锁可以按模式分类为乐观锁与悲观锁。 按粒度分可以分为全局锁、表级锁、页级锁、行级锁 按属性可以分为共享锁读锁/S锁、排它锁写锁/X锁 按状态分为意向共享锁、意向排它锁 按算法分为间隙锁、临键锁、记录锁。 全局锁 全局锁就是对整个数据库实例加锁 应用场景 一般用与数据备份 全库导出等全库操作 实现方式 Flush tables with read lock 当你需要让整个库处于只读状态的时候可以使用这个命令之后其他线程的以下语句会被阻塞数据更新语句数据的增删改、数据定义语句包括建表、修改表结构等和更新类事务的提交语句 风险 如果在主库上备份那么在备份期间都不能执行更新业务基本上就能停止。 如果在从库上备份那么备份期间从库不能执行主库同步过来的binlog会导致主从延迟 解决办法 mysqldump使用参数–single-transaction启动一个事务确保拿到一致性视图。而由于MVCC的支持这个过程中数据是可以正常更新的 表锁 当前操作的整张表加锁最常使用的 MyISAM 与 InnoDB 都支持表级锁定。 MySQL 里面表级别的锁有两种一种是表锁一种是元数据锁meta data lockMDL) 应用场景 读操作密集写操作少全表更新删除 实现方式 lock tables … read/write 例如lock tables t1 read, t2 write; 命令则其他线程写 t1、读写 t2 的语句都会被阻塞。同时线程 A 在执行 unlock tables 之前也只能执行读 t1、读写 t2 的操作。连写 t1 都不允许自然也不能在unlock tables之前访问其他表 元数据锁 MDL 不需要显式使用在访问一个表的时候会被自动加上在 MySQL 5.5 版本中引入了 MDL当对一个表做增删改查操作的时候加 MDL读锁当要对表做结构变更操作的时候加 MDL 写锁 MDL 是在事务提交后才会释放这意味着事务执行期间MDL 是一直持有的 风险 那如果数据库有一个长事务所谓的长事务就是开启了事务但是一直还没提交那在对表结构做变更操作的时候可能会发生意想不到的事情比如下面这个顺序的场景 首先线程 A 先启用了事务但是一直不提交然后执行一条 select 语句此时就先对该表加上 MDL 读锁然后线程 B 也执行了同样的 select 语句此时并不会阻塞因为「读读」并不冲突接着线程 C 修改了表字段此时由于线程 A 的事务并没有提交也就是 MDL 读锁还在占用着这时线程 C 就无法申请到 MDL 写锁就会被阻塞那么在线程 C 阻塞后后续有对该表的 select 语句就都会被阻塞如果此时有大量该表的 select 语句的请求到来就会有大量的线程被阻塞住这时数据库的线程很快就会爆满了。 为什么线程 C 因为申请不到 MDL 写锁而导致后续的申请读锁的查询操作也会被阻塞 这是因为申请 MDL 锁的操作会形成一个队列队列中写锁获取优先级高于读锁一旦出现 MDL 写锁等待会阻塞后续该表的所有 CRUD 操作。 解决方案 所以为了能安全的对表结构进行变更在对表结构变更前先要看看数据库中的长事务是否有事务已经对表加上了 MDL 读锁如果可以考虑 kill 掉这个长事务然后再做表结构的变更。 意向锁 在使用 InnoDB 引擎的表里对某些记录加上「共享锁」之前需要先在表级别加上一个「意向共享锁」在使用 InnoDB 引擎的表里对某些纪录加上「独占锁」之前需要先在表级别加上一个「意向独占锁」 也就是当执行插入、更新、删除操作需要先对表加上「意向独占锁」然后对该记录加独占锁。 如果没有「意向锁」那么加「独占表锁」时就需要遍历表里所有记录查看是否有记录存在独占锁这样效率会很慢。
那么有了「意向锁」由于在对记录加独占锁前先会加上表级别的意向独占锁那么在加「独占表锁」时直接查该表是否有意向独占锁如果有就意味着表里已经有记录被加了独占锁这样就不用去遍历表里的记录。
所以意向锁的目的是为了快速判断表里是否有记录被加锁
AUTO-INC锁 表里的主键通常都会设置成自增的这是通过对主键字段声明 AUTO_INCREMENT 属性实现的。 之后可以在插入数据时可以不指定主键的值数据库会自动给主键赋值递增的值这主要是通过 AUTO-INC 锁实现的。 AUTO-INC 锁是特殊的表锁机制锁不是再一个事务提交后才释放而是再执行完插入语句后就会立即释放。在插入数据时会加一个表级别的 AUTO-INC 锁然后为被 AUTO_INCREMENT 修饰的字段赋值递增的值等插入语句执行完成后才会把 AUTO-INC 锁释放掉。 那么一个事务在持有 AUTO-INC 锁的过程中其他事务的如果要向该表插入语句都会被阻塞从而保证插入数据时被 AUTO_INCREMENT 修饰的字段的值是连续递增的。 但是 AUTO-INC 锁再对大量数据进行插入的时候会影响插入性能因为另一个事务中的插入会被阻塞。 因此 在 MySQL 5.1.22 版本开始InnoDB 存储引擎提供了一种轻量级的锁来实现自增。 那么一个事务在持有 AUTO-INC 锁的过程中其他事务的如果要向该表插入语句都会被阻塞从而保证插入数据时被 AUTO_INCREMENT 修饰的字段的值是连续递增的。 但是 AUTO-INC 锁再对大量数据进行插入的时候会影响插入性能因为另一个事务中的插入会被阻塞。 因此 在 MySQL 5.1.22 版本开始InnoDB 存储引擎提供了一种轻量级的锁来实现自增。 行锁 InnoDB 引擎是支持行级锁的而 MyISAM 引擎并不支持行级锁。 前面也提到普通的 select 语句是不会对记录加锁的因为它属于快照读。如果要在查询时对记录加行锁可以使用下面这两个方式这种查询会加锁的语句称为锁定读。
//对读取的记录加共享锁
select ... lock in share mode;//对读取的记录加独占锁
select ... for update;上面这两条语句必须在一个事务中因为当事务提交了锁就会被释放所以在使用这两条语句的时候要加上 begin、start transaction 或者 set autocommit 0
行级锁的类型主要有三类
Record Lock记录锁也就是仅仅把一条记录锁上 针对行数据加锁锁住的是一条记录。而且记录锁是有 S 锁和 X 锁之分的 当一个事务对一条记录加了 S 型记录锁后其他事务也可以继续对该记录加 S 型记录锁S 型与 S 锁兼容但是不可以对该记录加 X 型记录锁S 型与 X 锁不兼容;当一个事务对一条记录加了 X 型记录锁后其他事务既不可以对该记录加 S 型记录锁S 型与 X 锁不兼容也不可以对该记录加 X 型记录锁X 型与 X 锁不兼容。 Gap Lock间隙锁锁定一个范围但是不包含记录本身 Gap Lock 称为间隙锁只存在于可重复读隔离级别目的是为了解决可重复读隔离级别下幻读的现象假设表中有一个范围 id 为35间隙锁那么其他事务就无法插入 id 4 这条记录了这样就有效的防止幻读现象的发生。 间隙锁虽然存在 X 型间隙锁和 S 型间隙锁但是并没有什么区别间隙锁之间是兼容的即两个事务可以同时持有包含共同间隙范围的间隙锁并不存在互斥关系因为间隙锁的目的是防止插入幻影记录而提出的。 Next-Key LockRecord Lock Gap Lock 的组合锁定一个范围并且锁定记录本身。 Next-Key Lock 称为临键锁是 Record Lock Gap Lock 的组合锁定一个范围并且锁定记录本身。 假设表中有一个范围 id 为35] 的 next-key lock那么其他事务即不能插入 id 4 记录也不能修改 id 5 这条记录。所以next-key lock 即能保护该记录又能阻止其他事务将新纪录插入到被保护记录前面的间隙中。 next-key lock 是包含间隙锁记录锁的如果一个事务获取了 X 型的 next-key lock那么另外一个事务在获取相同范围的 X 型的 next-key lock 时是会被阻塞的。 比如一个事务持有了范围为 (1, 10] 的 X 型的 next-key lock那么另外一个事务在获取相同范围的 X 型的 next-key lock 时就会被阻塞。 虽然相同范围的间隙锁是多个事务相互兼容的但对于记录锁我们是要考虑 X 型与 S 型关系X 型的记录锁与 X 型的记录锁是冲突的。 插入意向锁 一个事务在插入一条记录的时候需要判断插入位置是否已被其他事务加了间隙锁next-key lock 也包含间隙锁。 如果有的话插入操作就会发生阻塞直到拥有间隙锁的那个事务提交为止释放间隙锁的时刻在此期间会生成一个插入意向锁表明有事务想在某个区间插入新记录但是现在处于等待状态。 举个例子假设事务 A 已经对表加了一个范围 id 为35间隙锁。 当事务 A 还没提交的时候事务 B 向该表插入一条 id 4 的新记录这时会判断到插入的位置已经被事务 A 加了间隙锁于是事物 B 会生成一个插入意向锁然后将锁的状态设置为等待状态PSMySQL 加锁时是先生成锁结构然后设置锁的状态如果锁状态是等待状态并不是意味着事务成功获取到了锁只有当锁状态为正常状态时才代表事务成功获取到了锁此时事务 B 就会发生阻塞直到事务 A 提交了事务。插入意向锁名字虽然有意向锁但是它并不是意向锁它是一种特殊的间隙锁属于行级别锁。 如果说间隙锁锁住的是一个区间那么「插入意向锁」锁住的就是一个点。因而从这个角度来说插入意向锁确实是一种特殊的间隙锁。 插入意向锁与间隙锁的另一个非常重要的差别是尽管「插入意向锁」也属于间隙锁但两个事务却不能在同一时间内一个拥有间隙锁另一个拥有该间隙区间内的插入意向锁当然插入意向锁如果不在间隙锁区间内则是可以的。 页级锁 页级锁是 MySQL 中比较独特的一种锁定级别在其他数据库管理软件中并不常见。 页级锁的颗粒度介于行级锁与表级锁之间所以获取锁定所需要的资源开销以及所能提供的并发处理能力同样也是介于上面二者之间。另外页级锁和行级锁一样会发生死锁。 页级锁主要应用于 BDB 存储引擎。 乐观锁 乐观锁是相对悲观锁而言的乐观锁假设数据一般情况下不会造成冲突所以在数据进行提交更新的时候才会正式对数据的冲突与否进行检测如果发现冲突了则返回给用户错误的信息让用户决定如何去做。 应用场景
适用于读多写少因为如果出现大量的写操作写冲突的可能性就会增大业务层需要不断重试会大大降低系统性能。
实现方式
一般使用数据版本Version记录机制实现在数据库表中增加一个数字类型的“version”字段来实现。当读取数据时将version字段的值一同读出数据每更新一次对此version值加一。当我们提交更新的时候判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对如果数据库表当前版本号与第一次取出来的version值相等则予以更新否则认为是过期数据。
悲观锁 悲观锁正如其名具有强烈的独占和排他特性每次去拿数据的时候都认为别人会修改对数据被外界包括本系统当前的其他事务以及来自外部系统的事务处理修改持保守态度因此在整个数据处理过程中将数据处于锁定状态。 应用场景
适用于并发量不大、写入操作比较频繁、数据一致性比较高的场景。
实现方式
在MySQL中使用悲观锁必须关闭MySQL的自动提交set autocommit0。共享锁和排它锁是悲观锁的不同的实现它俩都属于悲观锁的范畴。
死锁 两个事务都持有对方需要的锁并等待对方释放且双方都不会释放自己的锁 产生死锁的必要条件 两个或者两个以上的事务两个事务都持有锁并申请新的锁锁资源同时只能被同一个事务持有或者不兼容事务之间因为持有锁和申请锁而互相等待 如何处理死锁 等待直至超时 当两个事务中有一个事务设置时间超过等待时间的阈值就将其回滚另外事务进行 innodb中innodb_lock_wait_timeout设置超时时间 但这个超时时间对于在线服务是不可接受的过大会导致在等待时间其他线程无法访问资源进入长时间等待状态过短容易误伤短时间锁的等待 进行死锁检测 死锁检测原理是构建一个以事务为顶点锁为边的有向图判断图中是否存在环存在即有死锁 一旦检测到死锁innodb会选择回滚undo量最小的事务让其他事务继续进行 如何避免死锁
合理设置索引使业务SQL尽量定位更少的行减少锁的竞争调整业务逻辑SQL执行顺序避免update/delete长时间持有锁的SQL在事务前面避免大事务尽量大事务拆解成多个小事务进行小事务减少资源锁定的时间发生锁冲突的情况更少降低隔离级别。如果业务允许将隔离级别从RR降低到RC可以减少因为gap锁造成的死锁
锁的内存结构
锁所在的事务信息 不论是表锁还是行锁都是在事务执行的过程中生成的所以我们需要记录生成锁的事务信息通过指针可以在内存中快速找到事务的信息 索引信息
对于行锁来说需要记录一下加锁的记录是属于哪个索引的也是一个指针
表锁/行锁信息
表锁记录对加锁表信息的记录
行锁记录 space_id 记录所在表空间 page_num 页号 n_bits 对于行锁来说一条记录对应着一个比特位一个页面中包含很多记录用不同的比特位来区别哪一条记录加了锁 type_mode lock_mode lock_type rec_lock_type 其他信息
为了更好的管理系统运行中生成的各种锁结构设计的各种哈希表和链表
