MySQL锁

本文详细介绍了MySQL的锁机制,包括全局锁、表级锁(表锁和MDL)和行锁,分析了它们的使用场景和潜在问题。强调了在事务中通过调整操作顺序减少锁冲突以提升并发度,并探讨了死锁的概念、检测及解决方案。此外,针对热点更新导致的性能问题,提出了关闭死锁检测和控制并发度的策略。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

MySQL中的锁大致可以分为全局锁、表级锁、行锁

全局锁

加全局锁的命令:Flush tables with read lock
全局锁主要的使用场景就是全局备份。
例如下图如果不加全局锁的话,会存在如下问题:
购买课程的操作,如果数据库是先备份余额表然后此时用户购买,然后数据库再备份用户课程表的话,就会出现我没有花钱但是多了一门课程的情况。

在这里插入图片描述
也就是说,如果不加锁的话,备份系统备份的得到的库不是一个逻辑时间点,这个视图是逻辑不一致的。

官方自带的逻辑备份工具是mysqldump。当mysqldump使用参数–single-transaction的时候,导数据之前就会启动一个事务,来确保拿到一致性视图。而由于MVCC的支持,这个过程中数据是可以正常更新的。

表级锁

mysql中表级锁分两种:1.表锁 2.元数据锁(MDL)
表锁的语句lock tables … read/write。可以用unlock table 释放锁,也可以在客户端断开的时候自动释放。
假如某个线程A中执行了lock tables t1 read, t2 write; 的话,其他线程写t1、读写t2都会阻塞。而线程A则只能读t1和读写t2.

另外一种表级锁MDL,MDL不需要显式使用,在访问一个表的时候会被自动加上。
MySQL5.5版本引入MDL,当对一个表做增删改查操作的时候,加MDL读锁;当对表结构变更操作的时候,加MDL写锁。
读锁之间不互斥,因此你可以有多个线程同时对一张表进行增删改查。
读写锁、写锁之间是互斥的,用来保证变更表结构操作的安全性。因此,如果有两个线程要同时给一个表加字段,其中一个要等另一个执行完才能开始执行。
虽然MDL是自动加的,但却是一个你不能忽略的机制。比如下面这个例子:给一个小表加字段导致整个数据库挂了。
你肯定知道给一个小表加字段,或者修改字段或者加索引,需要扫描全表的数据。在对大表操作的时候,你一定要特别小心,以免出现线上问题。而实际上,小表操作不慎也会出现问题。
假设表t是一个小表,我们看到session A先启动这时候会对表t加一个MDL读锁。然后由于session B需要的也是读锁,所以能正常工作。但是session C会被阻塞,因为session C需要的是写锁。如果只有session C自己被阻塞还没什么关系,但是之后所有要在表t上新申请MDL读锁的请求也会被session C阻塞。前面我们说了,所有对表的增删改查操作都需要先申请MDL读锁,就都被锁住,等于这个表现在完全不可读写了。
在这里插入图片描述
如何安全的给小表加字段?
首先要解决的是长事务问题,事务不提交就会一直占用MDL锁。在MSYSQL的information_schema 库的 innodb_trx 表中,你可以查看到正在执行的事务。如果你要做DDL刚好有长事务操作,你可以先暂停DDL或者kill掉这个长事务。

行锁

mysql的行锁是在引擎层由各个引擎来实现的。并不是所有引擎都支持行锁的,比如MYISAM引擎就不支持行锁。不支持行锁就意味着每一个表此时只能有一个更新在执行,会严重影响业务发展。这也是为什么innodb取代myisam的原因。

两阶段锁
在这里插入图片描述
在innodb事务中,行锁是在需要的时候被加上的,但并不是不需要的时候就立即释放,而是要等到事务结束的时候才释放,这就是两阶段提交协议。
**所以如果事务中如果需要锁多行,要把最可能造成锁冲突的,最可能影响并发度的操作往后放。**例如一个事务有以下几个操作:
1.从顾客A账户余额中扣除电影票价;
2.给影院B的账户余额增加这张电影票价;
3.记录一条交易日志。

那么如果多个人同时买票,造成锁冲突的语句就是2,所以如果我们将顺序改为3、1、2。2执行的时候会被加上行锁,然后事务执行结束就会被释放。这就最大程度地减少了事务之间的锁等待,提升了并发度。

死锁和死锁检测
在这里插入图片描述
当并发系统中不同线程出现循环资源依赖,涉及的线程都在等待别的线程释放资源时,就会导致这几个线程出现无限等待的状态,称为死锁。
出现死锁后有两种策略:
1.直接进入等待直到超时,这个超时时间可以通过innodb_lock_wait_timeout来进行设置。
2.另一个策略发起死锁检测,发现死锁后,主动回滚死锁链条中的某一事务,让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on表示开启这一逻辑。

方法2虽然能快速发现并处理,但是它有额外的负担。你可以想象一下这个过程:每当一个事务被锁住,就要看看线程有没有被别人锁住。如此循环,最终判断是否出现循环等待,也就是死锁。
那如果是我们上面说到的所有事务都要更新同一行的场景呢?
每个新来的被堵住的线程,都要判断会不会由于自己的加入导致了死锁,这是一个时间复杂度是O(n)的操作。假设有1000个并发线程要同时更新同一行,那么死锁检测操作就是100万这个量级的。虽然最终检测的结果是没有死锁,但是这期间要消耗大量的CPU资源。因此,你就会看到CPU利用率很高,但是每秒却执行不了几个事务。

那怎么解决这种热点更新导致的性能问题呢?
1.如果你确保这个业务一定不会出现死锁,就临时把死锁检测关了。
2.控制并发度,基本思路就是,对于相同行的更新,在进入引擎之前排队。这样在InnoDB内部就不会有大量的死锁检测工作了。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值