【MySQL】数据库管理过程中的锁问题

文章目录

  • 什么使用用全局锁?
  • 什么时候用表锁?
  • 什么时候用行锁?

按照锁的大小,我们分为全局锁,表锁,页锁,和行锁。
不同级别的锁有不同的作用,这里我简单列出我在工作过程中对这些锁的理解。

什么使用用全局锁?

全局锁是用来对整个数据库加锁的锁。
我们可以使用Flush Table With Read Lock(FTWRL)来让数据库进入只读状态。
使用这个命令之后,其他线程的如下操作会被阻塞:DML数据增删改操作,DDL数据定义操作,如建表,修改表结构等操作以及更新类事务的提交语句。

全局锁的使用场景在我们公司为:重要库的一天一次的全量备份,次要库的一周一次的全量备份。
做全库的逻辑备份,我们就需要保证再这段时间内没有新的数据,保证数据库只读,否则就会出现数据异常问题,之后恢复数据也会出现问题。
虽然说全局锁肯定也不太好,毕竟使用了全局锁就意味着主库备份时肯定不能写入修改数据了,而从库备份时也就不能同步主库过来的binlog日志,都会有些影响。
但是如果不加全局锁,再备份期间就会导致一些修改操作,而备份恢复的时候这些修改操作已经执行,从而导致的一些数据异常问题,所以加锁能帮助我们避免这些问题。
其实这也就是所谓的数据一致性问题而已,我们在备份的时候,如果可以记录对这些备份数据的修改,并且我们备份数据的时候,能先拿到一下这些数据的快照,那么似乎就可以解决这些数据不一致的问题了,所以就有了mysql自带的备份工具mysqldump。

当 mysqldump 使用参数–single-transaction的时候,导数据之前就会启动一个事务,来确保拿到一致性视图。而由于MVCC 的支持,这个过程中数据是可以正常更新的。但是对于 MyISAM这种不支持事务的引擎,如果备份过程中有更新,总是只能取到最新的数据,那么就破坏了备份的一致性。这时,我们就需要使用FTWRL命令了。所以,single-transaction方法只适用于所有的表使用事务引擎的库。如果有的表使用了不支持事务的引擎,那么备份就只能通过FTWRL 方法。

补充:内容来自《MySQL45讲》

为什么不使用 set global readonly=true 的方式呢?
readonly 方式也可以让全库进入只读状态,但我还是会建议你用 FTWRL 方式,主要有两个原因:
一是,在有些系统中,readonly 的值会被用来做其他逻辑,比如用来判断一个库是主库还是备库。因此,修改 global 变量的方式影响面更大,我不建议你使用。
二是,在异常处理机制上有差异。如果执行 FTWRL 命令之后由于客户端发生异常断开,那么 MySQL 会自动释放这个全局锁,整个库回到可以正常更新的状态。而将整个库设置为 readonly 之后,如果客户端发生异常,则数据库就会一直保持 readonly 状态,这样会导致整个库长时间处于不可写状态,风险较高。业务的更新不只是增删改数据(DML),还有可能是加字段等修改表结构的操作(DDL)。不论是哪种方法,一个库被全局锁上以后,你要对里面任何一个表做加字段操作,都是会被锁住的。

什么时候用表锁?

对于MyISAM这种不支持行锁的存储引擎,我们需要锁数据的时候就只能以表为单位来进行加锁,比如使用lock table xxx read/write的方式,并且使用unlock tables的方式来释放锁。
表锁的加锁消耗相比于行锁更小,但是由于锁的粒度比较大,因此容易导致并发问题。

当我们在某个线程使用lock table xxx 的方式来对一张表加上读锁的时候,其他线程只能读取当前这张表,如果写那么会阻塞,也就是我们所谓的读读不互斥,读写互斥。
而如果我们对一张表加了写锁,那么其他线程读取这张表的时候就会直接阻塞,可想而知,死锁的发生概率非常的大。

还要注意的一个锁是MDL元数据锁,这个锁不需要显式的调用,它的作用是帮助我们再执行操作的时候保证表结构不被修改。
同样的,我们在读(包括增删改查)取一个表的时候,会得到MDL读锁,读锁之间不互斥。
但是如果我们开始使用alter语句去修改表结构,那么我们必须确保能拿到MDL写锁,而写锁的获取需要保证前面没有读锁,否则前面有读锁时,写锁需要先阻塞,而此时写锁阻塞,再当前alter语句之后的所有语句,包括获取MDL读锁的语句也会进行阻塞,那么此时就又会出现死锁了。
所以我们一般再要进行alter语句的时候我们会设一个超时时间。

什么时候用行锁?

MySQL InnoDB 存储引擎的行锁是基于索引的。当执行一个含有 WHERE 条件的 SQL 查询时,InnoDB 存储引擎会根据相应的索引定位到符合条件的记录,并对这些记录加上行锁。

行锁的粒度是以记录为单位的,只有在命中对应的索引之后,才会对符合条件的记录进行行锁加锁。这种方式可以提高并发性能,因为只有真正需要锁定的记录才会被锁定,而不是对整个表或整个索引进行锁定。

需要注意的是,如果查询没有命中索引,而是使用全表扫描的方式进行,那么会出现全表锁(Table Lock),而不是行锁。全表锁会锁定整个表,对于并发性能会有一定的影响。因此,在设计数据库表和索引时,合理选择和创建合适的索引是非常重要的。

并且行锁的使用遵循两阶段锁原则,上面我也提到了,只有用到了某条记录才会对某条记录加锁,而如果两个事务都需要对同一个行锁进行修改,那么后来者需要等待先来者事务提交之后才会结束阻塞,否则需要等待事务提交。

也正是这个原因,我们应该需要确保最有可能导致阻塞的语句,放在最接近事务结束的地方,我们公司有一个SKU系统,我们会确保对SKU的操作一定是放在最后进行的,也就是一般情况都是我们的save/update语句的下一条语句就是return,确保对其他事务的影响最小。

随着上面的情况,如果我们的事务一修改了记录1,然后事务二修改了记录2,而之后当事务一需要操作记录2的时候,事务二需要操作记录1的时候就会出现死锁。

对于这种死锁,我们的计划是设定锁超时自动释放,参数为innodb_lock_wait_timeout,由于我们是下游,我们的上游接口有一定的时间,所以我们设定这个参数为10s左右。

mysql害提供了一个innodb_deadlock_detect,他会自动进行死锁检测,但是因为死锁检测的性能消耗是很高的。毕竟他需要扫描每一个事务对应的线程有没有被其他线程锁住,这很消耗性能。
所以我们编码的时候一般需要保证尽可能多的测试,确保业务尽可能不出现死锁,也就是从源头上减少出现死锁的可能性。

同时当初还考虑到由于死锁是出现在对同一行记录的操作,所以我们有的时候会把一条记录进行拆分,合并之后才是这条完整的记录,我们可以吧一些操作先操作在其他行上,或者说我们也会创建中间表,然后再一定时间之后合并操作。

你可能感兴趣的:(mysql,数据库,mysql)