mysql innodb存储引擎行级锁问题

一张表t字段只有id开启事务select*fromtwhereid<5forupdate;//应该只锁id小于5的行记录吧??因为innodb是行锁这时开启另外个事务in... 一张表t 字段只有id
开启事务 select * from t where id <5 for update;//应该只锁id小于5的行记录吧??
因为innodb是行锁
这时开启另外个事务
insert into t select 10;//此时却超时异常,为什么呢?上面那个事务不是只锁了id小于5的行记录吗
展开
 我来答
tourkpu
2016-07-21 · TA获得超过743个赞
知道小有建树答主
回答量:322
采纳率:0%
帮助的人:225万
展开全部
概念:
锁是用来管理对共享文件的并发访问。innodb会在行级别上对数据库上锁。不过innodb存储引擎会在数据库内部其他多个地方使用锁,从而允许对不同资源提供并发访问。例如操作缓冲池中的LRU列表,删除,添加,移动LRU列表中的元素,为了保证一致性,必须有锁的介入。MyISAM引擎是表锁,而InnoDB提供一致性的非锁定读、行级锁,且行级锁没有相关额外的开销。

table-level locking(表级锁)
整个表被客户锁定。根据锁定的类型,其他客户不能向表中插入记录,甚至从中读数据也受到限制MyISAM、MEMORY默认锁级别,个别时候,InnoDB也会升级为表级锁
row-level locking(行级锁)
只有线程当前使用的行被锁定,其他行对于其他线程都是可用的InnoDB默认行级锁。是基于索引数据结构来实现的,而不是像ORACLE的锁,是基于block的。InnoDB也会升级为表级锁,全表/全索引更新,请求autoinc锁等
page-level locking(页级锁)
锁定表中某些行集合(称做页),被锁定的行只对锁定最初的线程是可行。如果另外一个线程想要向这些行写数据,它必须等到锁被释放。不过其他页的行仍然可以使用BDB默认页级锁
lock与latch
latch称为闩锁(轻量级的锁),因为其要求锁定的时间必须非常短。若持续的时间长,则应用的性能会非常差。在InnoDB存储引擎中,又可以分为mutex(互斥量)和rwlock(读写锁)。其目的是用来保证并发线程操作临界资源的正确性,并且通常没有死锁检测的机制。latch可以通过命令show engine innodb mutex来进行查看。如图:

由上图可以看出列Type显示的总是InnoDB,列Name显示latch的信息以及所在源码的行数,列Status中显示的os_waits表示操作系统等待的次数。
lock的对象是事务,用来锁定的是数据库中的对象,如表、页、行。并且一般lock的对象仅在事务commit或者rollback后释放(不同事务隔离级别释放的时间可能不一样)。有死锁机制。二则的区别如下:

特点:
InnoDB是通过对索引上的索引项加锁来实现行锁。这种特点也就意味着,只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁。
锁的类型:
有两种标准的行级锁:
共享锁(S lock):允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁.SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
排它锁(X lock):允许获得排他锁的事务更新数据,阻止其他事务取得相同数据集的共享读锁和排他锁.SELECT * FROM table_name WHERE ... FOR UPDATE
InnoDB存储引擎支持意向锁且设计比较简练,分为两种内部使用的意向锁(Intention Locks),这两种意向锁都是表锁。(意向锁是InnoDB自动加的)
意向共享锁(IS):事务打算给数据行加行共享锁,事务在给一个数据行加共享锁前必须先取得该表的IS锁.
意向独占锁(IX):事务打算给数据行加行排他锁,事务在给一个数据行加排他锁前必须先取得该表的IX锁.
追问
能用自己的话或者复制这个问题的概念吗
慧咨环球
2024-02-09 广告
选择一个适合自己公司的仓库管理系统需要考虑以下几个因素:1. 公司的业务需求:不同公司的业务需求不同,需要选择适合自己业务需求的仓库管理系统。例如,有些公司需要管理多个仓库,有些公司需要管理拣货和打包等操作,有些公司需要管理库存和采购等环节... 点击进入详情页
本回答由慧咨环球提供
爱可生云数据库
2020-09-23 · MySQL开源数据库领先者
爱可生云数据库
爱可生,金融级开源数据库和数据云服务整体解决方案提供商;优秀的开源数据库技术,企业级数据处理技术整体解决方案提供商;私有云数据库云服务市场整体解决方案提供商。
向TA提问
展开全部
当 web 日志中出现行锁超时错误后,很多开发都会找我来排查问题,这里说下问题定位的难点!
1. MySQL 本身不会主动记录行锁等待的相关信息,所以无法有效的进行事后分析。
2. 锁争用原因有多种,很难在事后判断到底是哪一类问题场景,尤其是事后无法复现问题的时候。
3. 找到问题 SQL 后,开发无法有效从代码中挖掘出完整的事务,这也和公司框架-产品-项目的架构有关,需要靠 DBA 事后采集完整的事务 SQL 才可以进行分析。
已赞过 已踩过<
你对这个回答的评价是?
评论 收起
推荐律师服务: 若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询

为你推荐:

下载百度知道APP,抢鲜体验
使用百度知道APP,立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。
扫描二维码下载
×

类别

我们会通过消息、邮箱等方式尽快将举报结果通知您。

说明

0/200

提交
取消

辅 助

模 式