10bet网址
MySQL 8.0参考手册
相关文件10bet官方网站 本手册下载 从本手册中摘录

MySQL 8.0参考手册/....../ 锁定由InnoDB中的不同SQL语句设置

15.7.3 InnoDB中不同SQL语句设置的锁

一个锁定阅读,一个更新,或者删除通常在SQL语句处理过程中扫描的每条索引记录上设置记录锁。是否有都无所谓在哪里排除行的声明中的条件。Innodb.不记得确切的在哪里条件,但只知道扫描了哪个索引范围。锁通常是下一键锁这也阻止了插入差距就在录音前。然而,间隙锁定可以明确禁用,这会导致不使用下一个密钥锁定。有关更多信息,请参阅第15.7.1节“InnoDB锁定”.交易隔离级别也会影响设置哪个锁;看第15.7.2.1节“交易隔离级别”

如果在搜索中使用辅助索引并设置索引记录锁是独占的,Innodb.还要检索相应的群集索引记录并设置锁定锁。

如果您没有适合您的语句和MySQL必须扫描整个表来处理语句的索引,则表的每一行都被锁定,这又通过其他用户块块块到表中的所有插入。创建好索引是非常重要的,以便您的查询不会扫描比必要的更多行。

Innodb.设置具体类型的锁如下。

  • 选择......从是一个一致的读取,读取数据库的快照,除非将事务隔离级别设置为可序列化.为可序列化级别,搜索集所遇到的索引记录上的共享下一个键锁。但是,对于使用唯一索引锁定行以搜索唯一行的语句,只需要索引记录锁。

  • 选择...进行更新选择...分享使用唯一索引的语句获取扫描行的锁,并释放不符合结果集中包含在结果集中的行的锁(例如,如果它们不符合所提供的标准在哪里条款)。但是,在某些情况下,可能不会立即解锁行,因为在查询执行期间,结果行与其原始源之间的关系会丢失。例如,在联盟在评估它们是否有资格获得结果集之前,可能将从表中的扫描(和锁定)行插入临时表中。在这种情况下,临时表中的行与原始表中行的行的关系丢失,后者行不会解锁,直到查询执行结束。

  • 锁定读取选择更新或者分享),更新, 和删除语句,遵守的锁定依赖于语句是否使用唯一的搜索条件或范围类型搜索条件使用唯一索引。

    • 对于具有唯一搜索条件的唯一索引,Innodb.只锁定发现索引记录,而不是差距在它之前。

    • 对于其他搜索条件,以及非唯一索引,Innodb.锁定已扫描的索引范围,使用间隙锁或者下一键锁将其他会话插入到范围覆盖的间隙中。有关间隙锁和下一个钥匙锁的信息,请参阅第15.7.1节“InnoDB锁定”

  • 对于搜索遇到的索引记录,选择...进行更新阻止其他会话选择...分享或在某些交易隔离级别中读取。一致性读取忽略读取视图中存在的记录上设置的任何锁。

  • 更新......在哪里......在搜索遇到的每个记录上设置一个独家的下一键锁。但是,对于使用唯一索引锁定行以搜索唯一行的语句,只需要索引记录锁。

  • 什么时候更新修改聚集索引记录,对受影响的二级索引记录采取隐式锁。的更新在插入新的辅助索引记录之前执行重复检查扫描,以及在插入新的辅助索引记录时,Operation还对受影响的辅助索引记录采取共享锁。

  • 从...中删除......在搜索遇到的每个记录上设置一个独家的下一键锁。但是,对于使用唯一索引锁定行以搜索唯一行的语句,只需要索引记录锁。

  • 对插入的行设置排他锁。这个锁是一个索引记录锁,而不是下一个键锁(也就是说,没有间隙锁),并且不会阻止其他会话在插入行之前插入间隙。

    在插入行之前,设置了一种称为插入意图隙锁的间隙锁定。此锁定意图以这样的方式插入,即将在相同的索引间隙中插入同一索引间隙的多个事务时,如果它们未在间隙内的相同位置处不需要等待彼此。假设存在具有4和7的值的索引记录。尝试插入5和6的值的单独事务每个锁定在插入行上的独占锁定之前锁定4和7之间的间隙,但不彼此封锁,因为行是非灌注的。

    如果发生重复键错误,则设置重复索引记录上的共享锁定。如果有多个会话尝试在另一个会话已经具有独占锁定时,此使用共享锁可能会导致死锁。如果另一个会话删除该行,则会发生这种情况。假设一个Innodb.桌子T1.有以下结构:

    创建表T1(i int,主键(i))引擎= innodb;

    现在假设三个会话按顺序执行以下操作:

    第1节:

    开始交易;插入T1值(1);

    第2届:

    开始交易;插入T1值(1);

    第3节:

    开始交易;插入T1值(1);

    第1节:

    回滚;

    第1次第一次操作1获取行的独占锁。会话2和3的操作均导致重复键错误,并且它们都请求行的共享锁。会话1回滚后,它会在行上释放其独占锁,并授予会话2和3的排队共享锁定请求。此时,会话2和3死锁:由于另一个相同的锁,既不能获取行的独占锁。

    如果表已包含具有键值1的行,则会出现类似的情况,并且三个会话按顺序执行以下操作:

    第1节:

    开始交易;从T1中删除我= 1;

    第2届:

    开始交易;插入T1值(1);

    第3节:

    开始交易;插入T1值(1);

    第1节:

    犯罪;

    第1次第一次操作1获取行的独占锁。会话2和3的操作均导致重复键错误,并且它们都请求行的共享锁。当会话1提交时,它会在行上释放其独占锁,并且授予会话2和3的排队共享锁定请求。此时,会话2和3死锁:由于另一个相同的锁,既不能获取行的独占锁。

  • 插入...在重复的密钥更新时与简单的不同在发生重复密钥错误时,将排列在行上的行中,放置在行上的行中。拍摄独占索引记录锁定重复的主键值。独家的下一键锁是用于重复唯一的键值。

  • 代替是这样做的如果在唯一的键上没有碰撞。否则,将独占的下键锁放在要替换的行上。

  • 插入到t选择...从...在插入到中的每一行上设置一个独占索引记录锁(没有间隙锁定)T.如果交易隔离级别是读过承诺Innodb.搜索吗?年代作为一致的读(没有锁)。否则,Innodb.的行上设置共享的下一个键锁年代Innodb.必须在后一种情况下设置锁:在使用基于语句的二进制日志的前进恢复期间,必须以完全相同的方式执行每个SQL语句。

    创建表……选择……执行选择与共享的下一个键锁或一致的读取,如插入...选择

    当一个选择在结构中使用替换为t选择...从...或者更新t…WHERE col IN (SELECT…从s…)Innodb.在表中设置共享下一键锁年代

  • Innodb.在与之关联的索引结束时设置一个独占锁自动递增初始化先前指定的时列自动递增表上的列。

    innodb_autoinc_lock_mode = 0Innodb.使用特殊汽车公司表锁定模式在访问自动增量计数器时获得锁定并将其锁定并将其保持在当前SQL语句的末尾(不到整个事务结束)。其他客户端无法插入表格时汽车公司表锁定。发生相同的行为批量插入innodb_autoinc_lock_mode = 1.表级汽车公司锁不使用innodb_autoinc_lock_mode = 2.有关更多信息,请参阅第15.6.1.6节“InnoDB中的Auto_Increment处理”

    Innodb.获取先前初始化的值自动递增未设置任何锁的列。

  • 如果一个外键约束是在一个表上定义的,任何需要检查约束条件的插入、更新或删除都会在它查看的记录上设置共享记录级锁来检查约束。Innodb.在约束失败的情况下还设置这些锁。

  • 锁定表设置表锁,但它是高于上方的较高的mysql图层Innodb.设置这些锁的图层。Innodb.是否知道表锁innodb_table_locks = 1(默认)和autocommit = 0.和上面的mysql层Innodb.知道行级锁。

    否则,Innodb.自动死锁检测无法检测涉及这些表锁的死锁。此外,由于在这种情况下,较高的MySQL层不知道行级锁,因此可以在另一个会话当前具有行级锁的表上获取表锁。但是,如讨论的那样,这不会危及交易完整性第15.7.5.2节“死锁检测”

  • 锁定表如果,则在每个表上获取两个锁innodb_table_locks = 1(默认值)。除了在MySQL层上的表锁之外,它还获取Innodb.表锁。避免收购Innodb.表锁,设置innodb_table_locks = 0..如果不Innodb.收集表锁,锁定表即使其他交易锁定表的某些记录也完成。

    在MySQL 8.0中,innodb_table_locks = 0.对表没有明确锁定的表格没有影响锁定表...写.它确实对锁定读取或写入的表确实有一种效果锁定表...写隐式地(例如通过触发器)或通过锁定表...阅读

  • 全部Innodb.在事务提交或中止交易时释放交易所持的锁。因此,援引它并没有很大的意义锁定表Innodb.桌子自动提交= 1模式因为获得的Innodb.表锁将立即释放。

  • 不能在事务中间锁定其他表,因为锁定表执行隐含犯罪解锁表格