mysql的锁貌似有很多啊,查了大部分资料,
什么表锁,行锁,页锁
共享锁,排他锁,意向锁,读锁,写锁
悲观锁,乐观锁。。
我去,真想问一句,有没有 金锁?我还范冰冰呢。。。
哎呀怎么感觉好乱啊。那么把它好好整理总结下吧。
后边还有对在innodb下的mvcc理解与举例,在并发量的访问下如何保持高效一致?简单易懂了解下,听朋友说大公司面试也爱问这个。
表/行/页-锁:
表级锁(table-level locking):MyISAM和MEMORY存储引擎
行级锁(row-level locking) :InnoDB存储引擎
页面锁(page-level-locking):BDB存储引擎
表级锁:开销小,并发低,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度也最低。
行级锁:开销大,并发高,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。
页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。
共享/排他锁
共享锁又称读锁,是读取操作创建的锁。其他用户可以并发读取数据,但任何事务都不能对数据进行修改(获取数据上的排他锁),直到已释放所有共享锁。
排他锁又称写锁,如果事务T对数据A加上排他锁后,则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据,又能修改数据。
Mysiam锁模式
MyISAM在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,在执行更新操作(UPDATE、DELETE、INSERT等)前,会自动给涉及的表加写锁。
a、对MyISAM表的读操作(加读锁),不会阻塞其他进程对同一表的读请求,但会阻塞对同一表的写请求.只有当读锁释放后才会执行其它进程的写操作。
b、对MyISAM表的写操作(加写锁),会阻塞其他进程对同一表的读和写操作,只有当写锁释放后,才会执行其它进程的读写操作。
innodb锁模式
意向锁是InnoDB自动加的,不需要用户干预。
对于insert、update、delete,InnoDB会自动给涉及的数据加排他锁(X);对于一般的Select语句,InnoDB不会加任何锁,事务可以通过以下语句给显示加共享锁或排他锁。
共享锁: SELECT ... LOCK IN SHARE MODE;
排他锁: SELECT ... FOR UPDATE;
MVCC(Multiversion concurrency control)
一个很难懂得概念,查阅了很多资料与博客,下边做一个简单易懂的理解。
情景模拟:
在高并发的前提下,一定要注意这个前提。
事务L1修改某表中D的key值,还未提交;
事务L2同样也修改D的key值,提交;然后L1提交。
发生了什么?
L1从D读取key:123对应的值100
L2从D读取key:123对应的100
L1对值增加1,将key:123更新为100 + 1
L2对值增加2,将key:123更新为100 + 2
如果L1和L2串行执行,key:123对应的值将为103,但上面并发执行中L1的执行效果完全被L2所覆盖,实际key:123所对应的值变成了102。就因为L1事务没提交呢,L2又来了。
那如何处理呢?
方法一:
加锁呗。前边不都是在说这个锁的问题呢,把他加写锁,等L1执行完再执行L2。可以是可以,但是发生了排队,并发下降了。这是一种悲观一般把基于锁的并发控制机称成为悲观机制。
方法二:
为了实现可串行化,同时避免锁机制存在的各种问题,我们可以采用基于多版本并发控制(Multiversion concurrency control,MVCC)思想的无锁并发机制,终于把要说的引出来了!人们一般把基于锁的并发控制机称成为悲观机制(悲观锁),而把MVCC等机制称为乐观机制(乐观锁)。加入版本号的一个机制,由D维护该版本号,每次数据有更新就增加版本号,通过版本号来更加高效的管理事务一致性与高并发的问题。
因为锁机制是一种预防性的,读会阻塞写,写也会阻塞读,当锁定粒度较大,时间较长是并发性能就不会太好;而MVCC是一种后验性的,读不阻塞写,写也不阻塞读,等到提交的时候才检验是否有冲突,由于没有锁,所以读写不会相互阻塞,从而大大提升了并发性能。
以上就是Mysql-各种锁区分与MVCC的详解的内容,更多相关内容请关注PHP中文网(m.sbmmt.com)!
已抢16813个
抢已抢49779个
抢已抢184119个
抢已抢65985个
抢已抢350277个
抢已抢663965个
抢