MySQL - 锁机制

2021/07/13 database 共 1306 字,约 4 分钟
Bob.Zhu

读写锁

在多用户并发操作数据库的时候,可能出现一个读取、另外一个修改的操作, 为了避免出现读取错误的数据, 需要进行并发控制,可以通过实现一种由两种类型的锁组成的锁系统来解决问题。这两种类型的锁通常被称为 共享锁(share lock)和排他锁(exclusive lock),也叫做读锁(read lock)和写锁(write lock)。

读锁

读锁是共享的,或者说是相互不阻塞的。多个客户可以再同一时间读取同一个资源,而互不干扰。

写锁

写锁是排他的,也就是说一个写锁会阻塞其他的写锁和读锁,这是出于安全策略的考虑。

所粒度

一种提高共享资源并发的方式就是让锁定对象更具有选择性。尽量只锁定需要修改的部分数据,而不是所有的 资源。更理想的方式是,只对会修改的数据片进行精确的锁定。任何时候,锁定的数据量越少,则系统的并发 性越高,只要相互之间不发生冲突即可。

问题是加锁也需要消耗资源,锁的各种操作,包括获取锁、检查锁是否已经解除、释放锁,都会增加系统的开 销。如果系统需要花费大量的时间来管理锁,而不是存取数据,那么系统的性能就会因此受到影响。

所谓的锁策略,就是在锁的开销和数据的安全性之间寻求平衡,这种平衡当然也会影响到性能。

MySQL提供了多种选择,

表锁

表锁(table lock),表锁是 MySQL 中最基本的锁策略,并且是开销最小的策略。顾名思义,当一个用户 在对表进行写操作(插入、删除、更新等),就会锁定整张表,这会阻塞其他用户对该表的所有读写操作。 只有没有写锁时,其他读取的用户才能获得读锁,读锁之间是不相互阻塞的。

在特定场景中,表锁也可能有良好的性能。比如:READ LOCAL 表锁支持某些类型的并发写操作。另外, 写锁比读锁有更高的优先级,因此一个写锁清秋可能会被插入到读锁队列的前面(反之,读锁则不能插入到 写锁前面)

尽管存储引擎可以管理自己的锁,但是 MySQL 会使用各种有效的表锁来实现不同的目的。比如,服务器会 为诸如 ALTER TABLE 之类的语句使用表锁,而忽略存储引擎的锁机制

行锁

行级锁可以最大程度的支持并发处理,同时也带来了最大的锁开销。在 InnoDB 和 XtraDB,以及其他 一些存储引擎中实现了行级锁,而且只在存储引擎层实现。服务器层完成不了解存储引擎中的锁实现。

死锁

非权威解释: 死锁是指多个事务在同一资源上相互占用并请求锁定对方占用的资源而导致恶性循环的现象。当多个事 务试图以不同顺序锁定资源时就可能会产生死锁,多个事务同时锁定同一个资源时也会产生死锁。 为了解决死锁问题,数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统,例如InnoDB 存储引擎,越能检测到死锁的循环依赖,并立即返回一个错误。这种解决方式很有效,否则死锁会导致出 现非常慢的查询。还有一种解决方法,就是当查询的时间达到锁等待超时的设定后放弃锁请求,这种方 式通常来说不太好。InnoDB 目前处理死锁的方法是将持有最少行级排它锁的事务进行回滚。 死锁发生之后,只有部分或者完全回滚其中一个事务,才能打破死锁。对于事务型系统这是无法避免的, 所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需要重新执行因死锁回滚的事务即可。

参考资料

文档信息

Search

    Table of Contents