InnoDB 事务锁多版本分析

Innodb的事务实现原理？InnoDB是MySQL数据库中一种常用的存储引擎，它支持事务和行级锁，以下是InnoDB事务实现的基本原理：1. ACID属性：• InnoDB事务遵循ACID属性，确保事务的原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。

2. 多版本并发控制（MVCC）：• InnoDB使用多版本并发控制（MVCC）来实现事务的隔离性。

每个事务开始时，InnoDB会为其创建一个唯一的事务ID（Transaction ID）。

在InnoDB中，每行数据都包含两个隐藏的字段，分别是创建版本号和删除版本号。

创建版本号记录了事务ID，表示创建该版本的事务；删除版本号记录了删除该版本的事务ID，表示该版本的行已经被删除。

通过这种方式，InnoDB能够实现读取一致性快照，不同事务之间的读写操作互不干扰。

3. 事务日志（Redo Log）：• InnoDB使用事务日志来保证事务的持久性。

在事务提交前，将事务的变更写入事务日志。

如果系统崩溃，通过事务日志可以进行崩溃恢复，将已提交的事务的变更重新应用到数据库中，确保数据的一致性和持久性。

4. 事务提交和回滚：•当事务提交时，InnoDB将所有事务的变更写入磁盘。

如果事务需要回滚，InnoDB可以根据事务日志进行回滚操作。

事务提交和回滚的过程保证了事务的原子性和一致性。

5. 一致性快照读取：• InnoDB的一致性快照读取确保在一个事务中读取数据时，能够看到该事务开始时的一致性状态，而不受其他事务的影响。

通过MVCC和事务日志的支持，InnoDB能够实现这种一致性快照读取。

6. 行级锁：• InnoDB使用行级锁实现事务的隔离性。

不同的事务可以并发地访问同一表的不同行，而不会造成冲突。

InnoDB支持多种锁的模式，包括共享锁和排他锁，使得事务之间的并发性得以提高。

总体而言，InnoDB通过MVCC、事务日志和行级锁等机制，实现了高度并发、事务的隔离性和原子性，以及数据的一致性和持久性，从而确保了ACID属性的实现。

MySQLInnoDB（Spring）并发事务导致的死锁及解决⽅案前提：InnoDB存储引擎 + 默认的事务隔离级别 Repeatable Read⽤MySQL客户端模拟并发事务操作数据时，如下表按照时间的先后顺序执⾏命令，会导致死锁。

数据库数据如下，id为主键。

select * from a ;+----+| id |+----+| 3 |+----+| 8 |+----+| 11 |+----+时间会话A 会话B1 begin;2 delete from a where id = 4;3 begin;4 delete from a where id = 6;5 insert into a values(5);6 insert into a values(7);7 Query OK, 1 row affected8 ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction9 commit;为什么看似互不影响的事务会出现死锁的问题？我们⼀定听说过MySQL中存在共享锁(S锁)和排他锁(X锁)，可能听说过有意向共享锁(IS锁)和意向排他锁(IX锁)，上⾯出现死锁的情况，⼀定是存在这⼏种锁的相互等待。

InnoDB存储引擎实现共享锁（S Lock）和排它锁（X Lock）两种⾏级锁，注意：⾏锁！⾏锁！⾏锁！S Lock：允许事务读⼀⾏数据，多个事务可以并发的对⾏数据加S LockX Lock：允许事务删除或更新⼀⾏数据，只有⾏数据没有任何锁才可以获取X LockInnoDB⽀持意向共享锁（IS Lock）和意向排它锁（IX Lock），这两种锁是表级别的锁，但实际上也应⽤在⾏锁之中IS Lock：事务想要获得⼀张表中某⼏⾏的共享锁IX Lock：事务想要获得⼀张表中某⼏⾏的排它锁锁的分类：⾏锁锁定⼀⾏数据，即上⾯所说的共享锁和排他锁间隙锁锁定⼀个范围，但不包含记录本⾝。

innodb原理InnoDB是MySQL数据库中最常用的存储引擎之一，它是一个事务性存储引擎，支持ACID（原子性、一致性、隔离性和持久性）事务。

InnoDB的设计目标是提供高性能、高可靠性和高可扩展性的数据存储解决方案。

InnoDB的核心原理是MVCC（多版本并发控制），它通过在每个数据行上维护多个版本来实现并发控制。

每个版本都有一个时间戳，用于确定该版本的可见性。

当一个事务开始时，它会创建一个新的版本，并将其时间戳设置为当前时间。

在事务提交之前，该版本对其他事务不可见。

当事务提交时，该版本变为可见状态，其他事务可以看到该版本的数据。

InnoDB还使用了锁来实现并发控制。

它使用了两种类型的锁：共享锁和排他锁。

共享锁允许多个事务同时读取同一行数据，而排他锁则只允许一个事务对同一行数据进行写操作。

InnoDB还支持行级锁定，这意味着只锁定需要修改的行，而不是整个表或页面。

InnoDB还使用了缓冲池来提高性能。

缓冲池是一个内存区域，用于存储最常用的数据页。

当一个查询需要访问一个数据页时，InnoDB会首先检查缓冲池中是否存在该页。

如果存在，则直接从缓冲池中读取数据，否则从磁盘中读取数据，并将其存储在缓冲池中以供以后使用。

InnoDB还支持自动增量列和外键约束。

自动增量列是一种特殊的列，它会自动递增并分配一个唯一的值。

外键约束是一种关系约束，它确保在一个表中的数据引用另一个表中的数据时的一致性。

总之，InnoDB是一个高性能、高可靠性和高可扩展性的存储引擎，它使用MVCC、锁和缓冲池来实现并发控制和性能优化。

它还支持自动增量列和外键约束，使得数据的管理更加方便和可靠。

MySQLInnoDB事务锁源码分析⽬录1. Lock 与 Latch2. Repeatable Read3. Insert加锁流程3.1 lock mode3.2 加锁流程3.3 隐式锁4. Select 加锁流程本⽂前提：代码MySQL 8.0.13只整理Repeatable Read当前读。

Read Committed简单很多，另外快照读是基于MVCC不⽤加锁，所以不在本⽂讨论范畴。

1. Lock 与 LatchInnoDB中的lock是事务中对访问/修改的record加的锁，它⼀般是在事务提交或回滚时释放。

latch是在BTree上定位record的时候对Btree pages加的锁，它⼀般是在对page中对应record加上lock并且完成访问/修改后就释放，latch的锁区间⽐lock⼩很多。

在具体的实现中，⼀个⼤的transaction会被拆成若⼲⼩的mini transaction（mtr），如下图所⽰：有⼀个transaction，依次做了insert，select…for update及update操作，这3个操作分别对应3个mtr，每个mtr完成：在btree查找⽬标record，加相关page latch；加⽬标record lock，修改对应record释放page latch为什么要这么做呢？是为了并发，事务中的每⼀个操作，在步骤⼆完成之后，相应的record已经加上了lock保护起来，确保其他并发事务⽆法修改，所以这时候没必要还占着record所在的page latch，否则其他事务访问/修改相同page的不同record时，这本来是可以并⾏做的事情，在这⾥会被page latch会被卡住。

lock是存在lock_sys->rec_hash中，每个record lock在rec_hash中通过<space_id, page_no, heap_no>来标识latch是存在bufferpool对应page的block中，对应block->lock本⽂只关注lock相关的东西，latch后⾯单独搞⼀篇整理2. Repeatable Read具体每个隔离级别就不展开说了，这⾥主要说下RR，从名字上也能看出来，RR⽀持可重复度，也就是在⼀个事务中，多次执⾏相同的SELECT…FOR UPDATE应该看到相同的结果集（除本事务修改外），这个就要求SELECT的区间⾥不能有其他事务插⼊新的record，所以SELECT除了对满⾜条件的record加lock之外，对相应区间也要加lock来保护起来。

mysql之showengineinnodbstatus解读（转）add by zhj: 我第⼀次知道这个命令是线上服务出了问题，然后同事⽤这个命令去查看死锁。

但⽤这个命令看死锁有⼀定的局限性，它只能看到最后⼀次死锁，⽽且只能看到死锁环中的两个事务所执⾏的最后⼀条语句（即被死锁卡住的那条语句），看不到整个死锁环，也看到不整个事务的语句。

但是即使这亲，对我们来说也⾮常有⽤，因为⼀般来说，数据库同时存在多个死锁环的可能性⽐较⼩，⽽且有了死锁环中的事务的最后⼀条语句，我们找到整个死锁环不是太难。

"show engine innodb status"这个命令显⽰的内容是分段的，每⼀段⽤下⾯的格式开头。

我个⼈感觉，死锁那部分是最重要的，可以看到死锁发⽣的时间以及死锁环中的两个事务的卡住的那条语句。

我们可以从业务代码中找到该事务，然后分析出整个死锁环。

------------xxxx------------注：以下内容为根据《⾼性能mysql第三版》和《mysql技术内幕innodb存储引擎》的innodb status部分的个⼈理解，如果有错误，还望指正！！ innodb存储引擎在show engine innodb status（⽼版本对应的是show innodb status）输出中，显⽰除了⼤量的内部信息，它输出就是⼀个单独的字符串，没有⾏和列，内容分为很多⼩段，每⼀段对应innodb存储引擎不同部分的信息，其中有⼀些信息对于innodb开发者来说⾮常有⽤，但是，许多信息，如果你尝试去理解，并且应⽤到⾼性能innodb调优的时候，你会发现它们⾮常有趣，甚⾄是⾮常有必要的。

输出内容中包含了⼀些平均值的统计信息，这些平均值是⾃上次输出结果⽣成以来的统计数，因此，如果你正在检查这些值，那就要确保已经等待了⾄少30s的时间，使两次采样之间的积累⾜够长的统计时间并多次采样，检查计数器变化从⽽弄清其⾏为，并不是所有的输出都会在⼀个时间点上⽣成，因⽽也不是所有的显⽰出来的平均值会在同⼀时间间隔⾥重新再计算。

innodb底层原理InnoDB是一个开源的关系型数据库管理系统，由Oracle公司开发，作为MySQL的一部分。

它是一个高性能的存储引擎，被广泛应用于大规模的网站和应用程序中，并在生产和业务环境中得到广泛使用。

InnoDB的底层原理包括以下几个方面：1. 事务和锁机制InnoDB使用了多版本并发控制（MVCC）来实现事务支持和锁机制。

在MVCC中，每个事务都看到一个版本的数据，而不是实际的数据。

因此，每个事务都可以读取和修改不同版本的数据，而不与其他事务发生冲突，从而避免了锁的竞争。

2. 缓冲池InnoDB使用缓冲池来管理内存，将查询结果和修改操作缓存在内存中，从而提高了性能。

缓冲池是一个内存池，用于缓存表和索引的数据页。

3. 页结构InnoDB使用了固定大小的页来存储数据和索引。

每个页的大小默认为16KB，但可以通过配置文件进行修改。

页被组织为一个B+树结构，每个节点包含一个键值和一个指向下一个节点的指针。

4. 事务日志InnoDB使用了事务日志（redo log）来记录所有的修改操作，从而实现事务的持久性。

事务日志是一个循环缓冲区，包含多个日志文件，每个文件大小为1~2GB。

当一个事务提交时，相关的修改操作将写入事务日志中，而不是直接写入数据页。

5. 二次写InnoDB实现了二次写（double write）机制，用于保护数据页的完整性。

首先，InnoDB 将修改操作写入缓冲池中，然后再将其写入磁盘中。

如果写入磁盘过程中出现错误，InnoDB会使用二次写机制，将缓冲池中的数据重新写入磁盘。

6. 自适应哈希索引InnoDB使用了自适应哈希索引（adaptive hashing）来提高在缓冲池中定位数据的效率。

自适应哈希索引是一种特殊的哈希表，它存储在缓冲池中，并在之前使用过的数据页上创建索引，以及在新的数据页上动态创建索引。

7. 外键约束InnoDB支持外键约束，它可以确保关系型数据表之间的完整性。

innodb特点和适用场景InnoDB是MySQL数据库中的一种存储引擎，具有许多特点和适用场景。

1. 支持事务：InnoDB是一个事务性存储引擎，支持ACID（原子性、一致性、隔离性、持久性）特性。

事务可以保证数据库的数据操作的完整性和一致性，适用于要求高数据完整性和可靠性的应用场景，如银行系统、电子商务等。

2. 并发性能：InnoDB支持行级锁定，可以避免数据操作冲突，并发性能更好。

不同的事务可以并行执行而不会相互阻塞，提高数据库的并发处理能力。

3. 数据一致性：InnoDB采用多版本控制（MVCC）的方式来保证数据的一致性。

MVCC通过在每个数据行后面建一个版本链来实现多个事务同时访问同一个数据时不会相互影响。

这个特性使得InnoDB在高并发环境下能够提供较好的性能。

4. 外键约束：InnoDB支持外键约束，可以保持数据的完整性。

外键约束是指在一个表中的一些字段值必须在另一个表中的一些字段值存在。

这个特性非常适合用来保持数据的一致性和完整性。

5. 数据恢复和故障恢复：InnoDB具有较强的容灾和故障恢复能力。

它有一个日志文件，负责记录事务的操作，当数据库出现故障时，可以利用这个日志文件来进行数据恢复。

同时，InnoDB还支持在线备份和恢复功能，可以在数据库运行的同时进行备份和恢复。

6. 高效的读写性能：InnoDB对于大量的并发读写操作有较好的支持，可以根据系统的负载自动调整读写比例，从而提高数据库的性能。

7. 支持热备份和主从复制：InnoDB支持热备份，可以在不停机的情况下进行备份。

此外，InnoDB还支持主从复制，可以将数据从主服务器复制到多个从服务器，实现数据的冗余和负载均衡。

8. 存储空间和性能优化：InnoDB具有比较高的存储空间效率，采用了一系列的存储和压缩技术来减少数据的存储空间。

同时，InnoDB还有一些性能优化的特性，如缓冲池机制和自适应哈希索引等，可以提高数据库的查询性能。

innodb行锁实现原理InnoDB存储引擎支持行级锁定，对于高并发的数据库操作具有重要的意义。

在这篇文章中，我们将从原理出发，详细介绍InnoDB行级锁的实现机制。

1. 首先明确一点，InnoDB的行级锁是通过实现多版本并发控制来实现的。

在每条记录中，都会保存它的历史版本，也就是说，当一条记录被修改的时候，并不是直接将其覆盖成新值，而是将当前记录复制一份，存储在版本链中，并在新记录中保存新值。

2. 当一个事务要修改某个记录的时候，它首先会读取该记录的当前版本，并将其复制到事务的undo日志中。

这样，如果事务需要撤消操作，就可以利用undo日志将记录回滚到之前的状态。

3. 之后，该事务会将记录的行级锁定标记为“reserved”，表示它已经获得了该记录的独占访问权。

其它事务也可以读取该记录的当前版本，但是如果它们要修改该记录，必须等待该事务释放行级锁。

4. 当当前事务完成修改操作，并提交事务之后，它会释放所有已经获得的行级锁定，并将新版本的记录插入到记录链的末尾。

此时，其它事务就可以从最新版本的记录中读取数据。

5. 以上就是InnoDB实现行级锁定的主要过程。

需要注意的是，在某些情况下，InnoDB还会使用表级锁定来保护数据的完整性。

比如在向表中添加或删除索引的时候，InnoDB会为该表加上一个排它锁，防止其它事务对该表进行并发操作。

总结来说，InnoDB通过实现多版本并发控制和行级锁定机制，充分利用了硬件资源，提高了数据库系统的并发性能和可扩展性。

当然，为了保证数据的一致性和正确性，我们还需要合理地设置事务隔离级别、锁定粒度、调整查询语句等。

最终，通过优化和调整，我们可以使数据库系统运行得更加高效、稳定和安全。

innodb_locks表说明InnoDB Locks表是MySQL数据库中的一个系统表，用于记录当前正在进行的事务的锁信息。

在数据库中，锁是用来控制并发访问的机制，它可以确保多个事务之间的数据操作的正确性和一致性。

本文将详细介绍InnoDB Locks表的功能和用法，以及如何避免常见的问题和注意事项。

让我们来了解一下InnoDB Locks表的作用。

该表中的每一行代表一个事务的锁信息，包括锁类型、锁模式、锁的对象和持有锁的事务ID等。

通过查询InnoDB Locks表，可以了解到当前系统中所有正在进行的事务以及它们所持有的锁信息。

这对于调试和排查数据库并发访问问题非常有帮助。

在使用InnoDB Locks表时，需要注意以下几点。

首先，为了避免对数据库性能的影响，应尽量减少对InnoDB Locks表的查询操作。

频繁的查询操作会增加数据库的负载，降低系统的响应速度。

其次，由于InnoDB Locks表中记录的是当前正在进行的事务的锁信息，因此在查询时需要注意锁信息的实时性。

如果在查询之后又有新的事务加入或释放了锁，那么查询结果可能已经过时了。

还需要注意InnoDB Locks表中的锁信息是以事务为单位进行记录的。

一个事务可以持有多个锁，而一个锁也可以被多个事务持有。

这就意味着，在查询InnoDB Locks表时，可能会出现多个事务同时持有同一个锁的情况。

这时就需要根据事务的优先级和锁的类型来确定锁的获取顺序和释放顺序，以避免死锁的发生。

为了更好地使用InnoDB Locks表，我们可以结合其他系统表和工具来进行综合分析。

例如，可以通过查询InnoDB Locks表和InnoDB Transactions表来了解当前系统中所有正在进行的事务和它们所持有的锁信息。

另外，还可以使用InnoDB Status工具来获取更详细的系统状态信息，包括锁等待的情况和死锁的检测等。

在使用InnoDB Locks表时，还需要注意一些常见的问题和注意事项。