一、表级锁
1.读锁,lock table t_student read;添加了读锁,使得其他sessionA和sessionB都不能修改数据,仅仅可以读数据。
show processlist;查看进程,修改的时候状态是在等待表级锁,已经等待了8s
在解锁unlock tables;之后,修改数据的sql也执行成功,如下图所示
2.写锁,当某一个进程在对某一张表实施写锁后,在该进程如果完成了更新(写、insert、update、delete)之后,如果不释放写锁,其他的进程连查看这张表的权限都没有,只有等它释放写锁值,其他的进程才可以完成相应的操作。如果该进程没有对该表进行更新操作,其他的进程只能做查询操作,但是无法实现更新操作。
二、行级锁
myisam引擎不支持行级锁,InnoDB的引擎支持行级锁。但是InnoDB的引擎是通过给索引上的索引项加锁来实现的,这就意味着:只有通过索引条件检索数据,InnoDB才会使用行级锁,否则InnoDB将使用表锁。
如下图所示,sessionA和sessionB都在事务中对id为1的记录进行修改,sessionA先执行,于是sessionB阻塞了。这便是sessionA对id为1的行加了行级锁,导致其他session操作该行记录的时候被阻塞了。
再看下一个场景,sessionA修改id为1的记录,sessionB修改id为2的记录,却不会造成阻塞。因为行级锁依赖于索引。
但是值得注意的是,如果没有依赖索引去修改表,那么InnoDB的引擎默认使用的还是表级锁。例如该表t_student中id不是主键或索引,那么则启用表级锁。
三、死锁
本来sessionA和sessionB分别各自启用了id=1和id=2的行级锁,但是之后sessionA和sessionB又分别修改id=2和id=1的数据,相当于各自分别去操作本不属于自己的锁。就造成了死锁