InnoDB：InnoDB 锁 - 版本历史

2023年3月31日 (五) 15:14 Eijux

2023-03-31T15:14:44Z

←上一版本		2023年3月31日 (五) 23:14的版本
第1行：		第1行：
	[[category:~~MySQL~~]]		[[category:MySQL文档]]

	== 关于 ==		== 关于 ==

Eijux：/* 间隙锁（Gap Locks）【？？？】 */

2021-05-12T12:09:22Z

间隙锁（Gap Locks）【？？？】

←上一版本		2021年5月12日 (三) 20:09的版本
第80行：		第80行：
	</syntaxhighlight>		</syntaxhighlight>

	== 间隙锁（Gap ~~Locks）【？？？】~~ ==		== 间隙锁（Gap Locks） ==
	间隙锁定'''是对索引记录之间的间隙的锁定'''，或者是对第一个或最后一个索引记录之前的间隙的锁定。		间隙锁定'''是对索引记录之间的间隙的锁定'''，或者是对第一个或最后一个索引记录之前的间隙的锁定。
	: 例如，“SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE;”防止其他事务将 15 的值插入到 t.c1 列中，无论该列中是否已经有这样的值，因为'''该范围中所有现有值之间的间隙都被锁定'''。		: 例如，“SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE;”防止其他事务将 15 的值插入到 t.c1 列中，无论该列中是否已经有这样的值，因为'''该范围中所有现有值之间的间隙都被锁定'''。

Eijux：/* 记录锁（Record Locks）【？？？】 */

2021-05-12T12:09:10Z

记录锁（Record Locks）【？？？】

←上一版本		2021年5月12日 (三) 20:09的版本
第61行：		第61行：
	</syntaxhighlight>		</syntaxhighlight>

	== 记录锁（Record ~~Locks）【？？？】~~ ==		== 记录锁（Record Locks） ==
	记录锁'''是对索引记录的锁定'''。		记录锁'''是对索引记录的锁定'''。
	: 例如，“SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;”阻止任何其他事务插入，更新或删除 t.c1 的值为 10 的行。		: 例如，“SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;”阻止任何其他事务插入，更新或删除 t.c1 的值为 10 的行。

Eijux：/* 自动增量锁（AUTO-INC Locks） */

2021-05-12T12:03:50Z

自动增量锁（AUTO-INC Locks）

←上一版本		2021年5月12日 (三) 20:03的版本
第180行：		第180行：
	</syntaxhighlight>		</syntaxhighlight>

	== 自动增量锁（AUTO-INC ~~Locks）~~ ==		== 自动增量锁（AUTO-INC Locks）【表级锁】 ==
	AUTO-INC 锁是一种特殊的'''表级锁'''，'''由事务插入具有“AUTO_INCREMENT”列的表中获得'''。在最简单的情况下，如果一个事务正在向表中插入值，那么任何其他事务都必须 await 自己在该表中进行插入，以便第一个事务插入的行接收连续的主键值。		AUTO-INC 锁是一种特殊的'''表级锁'''，'''由事务插入具有“AUTO_INCREMENT”列的表中获得'''。在最简单的情况下，如果一个事务正在向表中插入值，那么任何其他事务都必须 await 自己在该表中进行插入，以便第一个事务插入的行接收连续的主键值。

2021年4月20日 (二) 18:43 Eijux

2021-04-20T18:43:36Z

←上一版本		2021年4月21日 (三) 02:43的版本
第1行：		第1行：
	[[category:MySQL]]		[[category:MySQL]]

			== 关于 ==
			* 关于 InnoDB 锁机制的进一步理解，见：'''[[InnoDB 锁机制解析]]'''

	== 共享锁和排他锁（Shared and Exclusive Locks）【行级锁】 ==		== 共享锁和排他锁（Shared and Exclusive Locks）【行级锁】 ==

Eijux：/* 意向锁（Intention Locks）【表级锁】 */

2021-04-20T18:40:02Z

意向锁（Intention Locks）【表级锁】

←上一版本		2021年4月21日 (三) 02:40的版本
第28行：		第28行：
	* 在事务可以获取表中某行的共享锁之前，它必须首先获取该表中的 IS 锁或更强的锁。		* 在事务可以获取表中某行的共享锁之前，它必须首先获取该表中的 IS 锁或更强的锁。
	* 在事务可以获取表中某行的排它锁之前，它必须首先获取该表中的 IX 锁。【？】		* 在事务可以获取表中某行的排它锁之前，它必须首先获取该表中的 IX 锁。【？】
			其意义是：
			# 如果没有意向锁的话，则需要遍历所有整个表判断是否有行锁的存在，以免发生冲突。
			# 如果有了意向锁，只需要判断该意向锁与即将添加的表级锁是否兼容即可。因为意向锁的存在代表了，有行级锁的存在或者即将有行级锁的存在。因而无需遍历整个表，即可获取结果。


	~~表级锁类型的兼容性汇总在以下矩阵中：【？？？】~~		表级锁类型的兼容性汇总在以下矩阵中：
	{\| class="wikitable"		{\| class="wikitable" style="width: 50%;"
	! !! X !! IX !! S !! IS		! !! X !! IX !! S !! IS
	\|-		\|-
第42行：		第45行：
	\| IS \|\| 冲突 \|\| 兼容 \|\| 兼容 \|\| 兼容		\| IS \|\| 冲突 \|\| 兼容 \|\| 兼容 \|\| 兼容
	\|}		\|}
			* 此处的“X”、“S”均为表级锁，而非行级锁：'''IX，IS是表级锁，不会和行级的X，S锁发生冲突。只会和表级的X，S发生冲突'''。【！！！】
	如果锁与现有锁兼容，则将其授予请求的事务，但如果与现有锁冲突，则不授予该请求。事务 await 直到冲突的现有锁被释放。如果锁定请求与现有锁定发生冲突并且由于会导致死锁而无法被授予，则会发生错误。		如果锁与现有锁兼容，则将其授予请求的事务，但如果与现有锁冲突，则不授予该请求。事务 await 直到冲突的现有锁被释放。如果锁定请求与现有锁定发生冲突并且由于会导致死锁而无法被授予，则会发生错误。


	除了全表请求（例如“LOCK TABLES ... WRITE”）之外，意图锁不会阻止任何其他操作。'''意图锁定的主要目的是表明有人正在锁定表中的行，或者打算锁定表中的行'''。		除了全表请求（例如“LOCK TABLES ... WRITE”）之外，意图锁不会阻止任何其他操作。'''意图锁定的主要目的是表明有人正在锁定表中的行，或者打算锁定表中的行'''。
			*【在实际中，手动锁表的情况并不常见，所以意向锁并不常用。特别是之后 MySQL 引入了 '''MDL''' 锁，解决了 DML 和 DDL 冲突的问题，意向锁就更不被提起来了。】

2021年4月20日 (二) 18:22 Eijux

2021-04-20T18:22:43Z

←上一版本		2021年4月21日 (三) 02:22的版本
第182行：		第182行：


	要处理涉及 SPATIAL ~~索引的操作的锁定，下一键锁不能很好地支持“REPEATABLE~~ READ”或“SERIALIZABLE”事务隔离级别。多维数据中没有绝对排序概念，因此不清楚哪个是“下一个”键。		要处理涉及 SPATIAL 索引的操作的锁定，“临键锁”不能很好地支持“REPEATABLE READ”或“SERIALIZABLE”事务隔离级别。多维数据中没有绝对排序概念，因此不清楚哪个是“下一个”键。


	为了支持具有 SPATIAL 索引的表的隔离级别，InnoDB 使用了谓词锁。 SPATIAL 索引包含最小边界矩形（MBR）值，因此 InnoDB 通过在用于查询的 MBR 值上设置谓词锁定来强制对索引进行一致的读取。其他事务不能插入或修改将匹配查询条件的行。		为了支持具有 SPATIAL 索引的表的隔离级别，InnoDB 使用了谓词锁。 SPATIAL 索引包含最小边界矩形（MBR）值，因此 InnoDB 通过在用于查询的 MBR 值上设置谓词锁定来强制对索引进行一致的读取。其他事务不能插入或修改将匹配查询条件的行。

Eijux：/* 下一键锁（Next-Key Locks，临键锁）【记录锁和间隙锁的组合】 */

2021-04-20T18:21:47Z

下一键锁（Next-Key Locks，临键锁）【记录锁和间隙锁的组合】

←上一版本		2021年4月21日 (三) 02:21的版本
第96行：		第96行：
	* 使用“'''READ COMMITTED'''”隔离级别或启用“innodb_locks_unsafe_for_binlog”还有其他效果。 '''MySQL 评估“WHERE”条件后，将释放不匹配行的记录锁'''。对于“UPDATE”语句，InnoDB 进行“半一致”读取，以便将最新的提交版本返回给 MySQL，以便 MySQL 可以确定该行是否与UPDATE的WHERE条件匹配。		* 使用“'''READ COMMITTED'''”隔离级别或启用“innodb_locks_unsafe_for_binlog”还有其他效果。 '''MySQL 评估“WHERE”条件后，将释放不匹配行的记录锁'''。对于“UPDATE”语句，InnoDB 进行“半一致”读取，以便将最新的提交版本返回给 MySQL，以便 MySQL 可以确定该行是否与UPDATE的WHERE条件匹配。

	== ~~下一键锁（Next~~-Key ~~Locks，临键锁）【记录锁和间隙锁的组合】~~ ==		== 临键锁（Next-Key Locks）【记录锁和间隙锁的组合】 ==
	~~下一键锁是~~'''“索引记录上的记录锁”和“索引记录之前的间隙上的间隙锁”的组合'''。		临键锁是'''“索引记录上的记录锁”和“索引记录之前的间隙上的间隙锁”的组合'''。


	InnoDB 执行行级锁定的方式是：当它搜索或扫描表索引时，它会对遇到的索引记录设置共享或排他锁。因此，'''行级锁实际上是索引记录锁'''~~。索引记录上的“下一键锁”也会影响该索引记录之前的“间隙”。即，下一键锁定是索引记录锁加上索引记录之前的间隙上的间隙锁。~~		InnoDB 执行行级锁定的方式是：当它搜索或扫描表索引时，它会对遇到的索引记录设置共享或排他锁。因此，'''行级锁实际上是索引记录锁'''。索引记录上的“临键锁”也会影响该索引记录之前的“间隙”。即，临键锁是索引记录锁加上索引记录之前的间隙上的间隙锁。
	: 如果一个会话在索引中的记录 R 上具有共享或排他锁，则另一会话无法按照索引 Sequences 在 R 之前的间隙中插入新的索引记录。		: 如果一个会话在索引中的记录 R 上具有共享或排他锁，则另一会话无法按照索引 Sequences 在 R 之前的间隙中插入新的索引记录。


	假定索引包含值 10、11、13 和 ~~20。此索引的可能的下一键锁定涵盖以下间隔，其中，圆括号表示排除区间端点，方括号表示包括端点：~~		假定索引包含值 10、11、13 和 20。此索引的可能的临键锁定涵盖以下间隔，其中，圆括号表示排除区间端点，方括号表示包括端点：
	<syntaxhighlight lang="mysql">		<syntaxhighlight lang="mysql">
	(negative infinity, 10]		(negative infinity, 10]
第112行：		第112行：
	(20, positive infinity)		(20, positive infinity)
	</syntaxhighlight>		</syntaxhighlight>
	~~对于最后一个间隔，“下一键锁”将锁定索引中最大值之上的间隙，并且“supremum”（上限）伪记录的值高于索引中实际的任何值。~~		对于最后一个间隔，“临键锁”将锁定索引中最大值之上的间隙，并且“supremum”（上限）伪记录的值高于索引中实际的任何值。
	* ~~上限不是真的索引记录，因此，实际上，此下一键锁定仅锁定跟随最大索引值的间隙。~~		* 上限不是真的索引记录，因此，实际上，此临键锁仅锁定跟随最大索引值的间隙。


	'''默认情况下，InnoDB 以“REPEATABLE READ”事务隔离级别运行'''。在这种情况下，InnoDB ~~使用“下一键锁”进行搜索和索引扫描，这可以防止幻像行。~~		'''默认情况下，InnoDB 以“REPEATABLE READ”事务隔离级别运行'''。在这种情况下，InnoDB 使用“临键锁”进行搜索和索引扫描，这可以防止幻像行。


	~~下一键锁定的事务处理数据在“SHOW~~ ENGINE INNODB STATUS”和 InnoDB monitor 的输出如下：		临键锁定的事务处理数据在“SHOW ENGINE INNODB STATUS”和 InnoDB monitor 的输出如下：
	<syntaxhighlight lang="mysql">		<syntaxhighlight lang="mysql">
	RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`		RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`

Eijux：/* 下一键锁（Next-Key Locks）【记录锁和间隙锁的组合】 */

2021-04-20T18:17:20Z

下一键锁（Next-Key Locks）【记录锁和间隙锁的组合】

←上一版本		2021年4月21日 (三) 02:17的版本
第96行：		第96行：
	* 使用“'''READ COMMITTED'''”隔离级别或启用“innodb_locks_unsafe_for_binlog”还有其他效果。 '''MySQL 评估“WHERE”条件后，将释放不匹配行的记录锁'''。对于“UPDATE”语句，InnoDB 进行“半一致”读取，以便将最新的提交版本返回给 MySQL，以便 MySQL 可以确定该行是否与UPDATE的WHERE条件匹配。		* 使用“'''READ COMMITTED'''”隔离级别或启用“innodb_locks_unsafe_for_binlog”还有其他效果。 '''MySQL 评估“WHERE”条件后，将释放不匹配行的记录锁'''。对于“UPDATE”语句，InnoDB 进行“半一致”读取，以便将最新的提交版本返回给 MySQL，以便 MySQL 可以确定该行是否与UPDATE的WHERE条件匹配。

	== 下一键锁（Next-Key ~~Locks）【记录锁和间隙锁的组合】~~ ==		== 下一键锁（Next-Key Locks，临键锁）【记录锁和间隙锁的组合】 ==
	下一键锁是'''“索引记录上的记录锁”和“索引记录之前的间隙上的间隙锁”的组合'''。		下一键锁是'''“索引记录上的记录锁”和“索引记录之前的间隙上的间隙锁”的组合'''。

Eijux：/* 共享锁和排他锁（Shared and Exclusive Locks）【行级锁】 */

2021-04-20T18:11:06Z

共享锁和排他锁（Shared and Exclusive Locks）【行级锁】

←上一版本		2021年4月21日 (三) 02:11的版本
第5行：		第5行：
	# 共享（S）锁允许持有锁的事务读取一行。		# 共享（S）锁允许持有锁的事务读取一行。
	# 排他（X）锁允许持有锁的事务更新或删除行。		# 排他（X）锁允许持有锁的事务更新或删除行。
			'''共享锁/排他锁，即读/写锁'''。

InnoDB：InnoDB 锁 - 版本历史

2023年3月31日 (五) 15:14 Eijux

Eijux：​/* 间隙锁（Gap Locks）【？？？】 */

Eijux：​/* 记录锁（Record Locks）【？？？】 */

Eijux：​/* 自动增量锁（AUTO-INC Locks） */

2021年4月20日 (二) 18:43 Eijux

Eijux：​/* 意向锁（Intention Locks）【表级锁】 */