1.Mysql锁的基本介绍
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中,除传统的计算资源(CPU,IO,RAM)的竞争外,数据也是许多用户共享的资源,如何保证数据并发访问的一致性,是所有数据库必须解决的一个问题,锁冲突也是影响数据库并发访问的一个重要因素,从这个角度而言,锁对于数据库显得尤为重要,也更加复杂。
Mysql由于自身架构问题,最显著的特点是不同的存储引擎支持不同的锁机制。比如,MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking)。InnoDB存储引擎即支持行级锁(row-level locking),也支持表级锁,但是默认情况下,采用行级锁。表级锁:开销小,加锁快;不会出现死锁;锁的粒度大,发生锁冲突的概率最高,并发度最低。行级锁:开销大,加锁慢;会出现死锁;锁的粒度小,发生锁冲突的概率最低,并发度也最高。
从上述特点可见,很难笼统的说哪种锁更好,只能就具体的应用场景来说哪种锁更合适!仅从锁的角度来说:表级锁更适合以查询为主,只有少量按索引条件更新数据的应用,如web应用;而行级锁则更适合于大量按索引条件并发更新少量不同数据,同时又有并发查询的应用,如一些在线事务处理系统(OLTP)。
2.MyISAM表锁表共享读锁(Table Read Lock)
对MyISAM表的读操作,不会堵塞其他用户对同一表的读操作,但会堵塞对同一表的写请求。
案例:
在session1中获得mylock表的read锁
session1可以正常查询该表记录
当session1更新该表记录时报错
session1不能查询其他没有锁定的表
session2可以正常查询该表的记录
当session2更新该表记录时会等待获取锁
直到session1释放锁,session2会获得锁,更新成功
表独占写锁(Table Write Lock)
对MyISAM表的写操作,则会阻塞其他用户对同一表的读和写操作。
案例:
在session1中获得mylock表的write锁
session1可正常查询,更新该表
session2查询更新该表则会等待获取锁
直到session1释放锁时,session2才会执行成功
注意:MyISAM在执行查询语句之前,会自动给所涉及的表加读锁,在执行更新操作前会自动给所涉及的表加写锁,这个过程并不需要外界干预。
MyISAM的并发插入(ConcurrentInsert)特性
MyISAM表的读和写是串行的,但是MyISAM存储引擎中有一个系统变量Concurrent_insert专门用来控制并发插入行为,可以设置为0,1,2。具体说明如下:
concurrent_insert=0,不允许并发插入。
concurrent_insert=1,如果MyISAM表中没有空洞(即表的中间没有被删除的行),MyISAM允许在一个进程读表的同时,另一个进程从表尾插入记录。这也是MySQL的默认设置;
concurrent_insert=2,无论MyISAM表中有没有空洞,都允许在表尾并发插入记录;
案例:
session1获的mylock表的read锁(并发插入)
session1不能执行更新操作,不能查询其他未锁定的表
session2可以正常插入记录,无需等待锁,但是update会被阻塞
session1不能查询session2插入的记录
session1释放锁后,可以查询到session2刚才插入的记录
查询表级锁的竞争情况
这里有两个变量记录了Mysql内部表级锁的情况:
Table_locks_immediate:产生表级锁定的次数;
Table_locks_waited:出现表级锁竞争而发生等待的次数;
两个状态值都是从系统启用后开始记录,出现一次对应的事件则数量加1。如果这里的Table_locks_waited状态值比较高,那么说明系统中表级锁竞争情况比较严重。
3.InnoDB行锁共享锁(s):同一数据对象可以拥有多个事务的共享锁,此数据对象只能被查询,不可被更新,并且会阻止被加排他锁。排他锁(X):获取排他锁的事务可以进行更新操作,其他事务可以查询但不可更新,并且其他事务不可再获得该数据对象的共享锁和排他锁。
在InnoDB存储引擎中,update,insert,delete都会自动给涉及的数据加上排他锁,select语句默认不会加任何锁类型,如果加排他锁可以使用for update,加共享锁可以使用lock in share model。
InnoDB行锁的实现方式
InnoDB行锁是通过给索引列上的索引加锁来实现的,这一点和oracle不同,oracle是通过对数据块中的相应数据加锁实现的。InnoDB这种实现方式意味着:只有通过索引条件检索数据,InnoDB才会使用行锁,否则,将使用表锁!