我要评论一、前言
对于行锁和表锁的含义区别，在面试中应该是高频出现的，我们应该对mysql中的锁有一个系统的认识，更详细的需要自行查阅资料，本篇为概括性的总结回答。
mysql常用引擎有myisam和innodb，而innodb是mysql默认的引擎。myisam不支持行锁，而innodb支持行锁和表锁。
相对其他数据库而言，mysql的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。
mysql大致可归纳为以下3种锁：
- 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
- 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
- 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
如何加锁？
myisam在执行查询语句（select）前，会自动给涉及的所有表加读锁，在执行更新操作（update、delete、insert等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此用户一般不需要直接用lock table命令给myisam表显式加锁。
显式加锁：
上共享锁（读锁）的写法：lock in share mode，例如：
select math from zje where math>60 lock in share mode；
上排它锁（写锁）的写法：for update，例如：
select math from zje where math >60 for update；
二、表锁
不会出现死锁，发生锁冲突几率高，并发低。
myisam引擎
myisam在执行查询语句（select）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。
mysql的表级锁有两种模式：
- 表共享读锁
- 表独占写锁
读锁会阻塞写，写锁会阻塞读和写
- 对myisam表的读操作，不会阻塞其它进程对同一表的读请求，但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其它进程的写操作。
- 对myisam表的写操作，会阻塞其它进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作。
myisam不适合做写为主表的引擎，因为写锁后，其它线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞
三、行锁
会出现死锁，发生锁冲突几率低，并发高。
在mysql的innodb引擎支持行锁，与oracle不同，mysql的行锁是通过索引加载的，也就是说，行锁是加在索引响应的行上的，要是对应的sql语句没有走索引，则会全表扫描，行锁则无法实现，取而代之的是表锁，此时其它事务无法对当前表进行更新或插入操作。
create table `user` ( `name` varchar(32) default null, `count` int(11) default null, `id` int(11) not null auto_increment, primary key (`id`) ) engine=innodb auto_increment=7 default charset=utf8 -- 这里，我们建一个user表，主键为id -- a通过主键执行插入操作，但事务未提交 update user set count=10 where id=1; -- b在此时也执行更新操作 update user set count=10 where id=2; -- 由于是通过主键选中的，为行级锁，a和b操作的不是同一行，b执行的操作是可以执行的 -- a通过name执行插入操作，但事务未提交 update user set count=10 where name='xxx'; -- b在此时也执行更新操作 update user set count=10 where id=2; -- 由于是通过非主键或索引选中的，升级为为表级锁， -- b则无法对该表进行更新或插入操作，只有当a提交事务后，b才会成功执行
for update
如果在一条select语句后加上for update，则查询到的数据会被加上一条排它锁，其它事务可以读取，但不能进行更新和插入操作
-- a用户对id=1的记录进行加锁 select * from user where id=1 for update; -- b用户无法对该记录进行操作 update user set count=10 where id=1; -- a用户commit以后则b用户可以对该记录进行操作
行锁的实现需要注意：
- 行锁必须有索引才能实现，否则会自动锁全表，那么就不是行锁了。
- 两个事务不能锁同一个索引。
- insert，delete，update在事务中都会自动默认加上排它锁。
行锁场景：
a用户消费，service层先查询该用户的账户余额，若余额足够，则进行后续的扣款操作；这种情况查询的时候应该对该记录进行加锁。
否则，b用户在a用户查询后消费前先一步将a用户账号上的钱转走，而此时a用户已经进行了用户余额是否足够的判断，则可能会出现余额已经不足但却扣款成功的情况。
为了避免此情况，需要在a用户操作该记录的时候进行for update加锁
扩展：间隙锁
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，innodb会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内并不存在的记录，叫做间隙
innodb也会对这个"间隙"加锁，这种锁机制就是所谓的间隙锁
-- 用户a update user set count=8 where id>2 and id<6 -- 用户b update user set count=10 where id=5;
如果用户a在进行了上述操作后，事务还未提交，则b无法对2~6之间的记录进行更新或插入记录，会阻塞，当a将事务提交后，b的更新操作会执行。
建议：
- 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
- 合理设计索引，尽量缩小锁的范围
- 尽可能减少索引条件，避免间隙锁
- 尽量控制事务大小，减少锁定资源量和时间长度
到此这篇关于mysql 行锁和表锁的含义及区别详解的文章就介绍到这了,更多相关mysql 行锁和表锁内容请搜索移动技术网以前的文章或继续浏览下面的相关文章希望大家以后多多支持移动技术网！
您可能感兴趣的文章:
如您对本文有疑问或者有任何想说的，请 点击进行留言回复，万千网友为您解惑！
网友评论