MySQL事务底层原理

已于 2023-11-12 20:05:12 修改
阅读量415 收藏 1
点赞数
分类专栏： 数据库 文章标签： mysql 数据库
于 2023-09-28 16:02:57 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_33375499/article/details/132971618
版权

事务

【MySQL系统架构设计】
【MySQL索引设计与选择】
【MySQL事务底层原理】

一、MVCC机制

在了解 MySQL 事务时，首先我们需要明确一个概念 MVCC 机制。MVCC（Multi-Version Concurrency Control）是一种数据库管理系统中常见的并发控制机制，用于管理多个事务同时访问数据库时的数据一致性和隔离性。MVCC的核心思想是为每个事务创建一个可见的、独立的数据版本，而不是锁定整个表或数据行，从而允许多个事务并发执行而不相互干扰。

MySQL 的高速读写能力，离不开对 MVCC 的具体实现，引入 MVCC 后，数据库操作只有写写之间是相互阻塞，读写、写读、读读都是可以并行的。

在了解MVCC多版本并发控制之前，我们必须先了解一下，什么是 MySQL InnoDB 下的 当前读 和 快照读。

1.1 当前读

指读取的记录是最新版本，读取时还需保证其他并发事务不能修改当前记录，需要对读取记录进行加锁。比如 select ... lock in share mode、select … for update、update、insert、delete 这些操作都是一种当前读。

1.2 快照读

指不对select操作进行加锁的读取。

快照读的出现，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC，它在很多情况下，避免了加锁操作，降低了开销。在并发事务下，快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。

在 InnoDB 中，快照读的前提是事务隔离级别不能为 串行化，在串行化级别下的快照读会退化为当前读；

二、MySQL MVCC实现原理

MVCC 主要目的是为了解决 读写冲突，在 MySQL InnoDB 中，主要通过行记录中3个隐式字段，undo log，read view来实现，下面我们详细分析一下这三个具体作用。

2.1 行记录3个隐式字段

在 MySQL InnoDB 数据行中，除了记录我们自定义的字段外，数据库还隐式定义了 DB_TRX_ID、DB_ROLL_PTR 和 DB_ROW_ID 等隐式字段。

  • DB_ROW_ID：隐含的自增ID（隐藏主键），占6byte。如果数据表没有主键，InnoDB会自动以 DB_ROW_ID 生成一个聚簇索引。
  • DB_TRX_ID：最近修改(修改/插入)事务ID，占6byte。用于记录当前记录最后一次修改的事务ID，每次事务修改自动+1。
  • DB_ROLL_PTR：回滚指针，占7byte。指向这条记录的上一个版本 (存储于rollback segment回滚段里)，通过当前指针才能查找之前版本的数据。

2.2 Undo Log

MySQL 在进行数据操作是，需要将记录先读取到 Buffer Pool 中，然后进行修改，最后再进行刷盘，为了保证数据的持久性，在进行修改后，需写入一个 Undo Log 日志，记录修改后的数据，以便后续崩溃恢复。

Undo Log 日志主要分为两种：

  • Insert Undo Log：记录 MySQL 进行 INSERT 时产生的 Undo Log。只需要在事务回滚时需要，事务提交后可立即删除。
  • Update Undo Log：记录 MySQL 进行 UPDATE、DELETE 时产生的 Undo Log。在事务回滚时需要，在快照读时也需要；不能立即删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被 purge 线程统一清理。

不同事务或者相同事务的对同一记录的修改，会导致该记录的 Undo Log 成为一条记录版本线性表，既链表，Undo Log 的链首就是最新的旧记录，链尾就是最早的旧记录。

2.2.1 purge线程

为了实现 InnoDB 的 MVCC 机制，更新或者删除操作都只是设置一下旧记录的 delete_mask，并不真正将旧记录删除。并且为了节省磁盘空间，InnoDB有专门的 purge 线程来清理 delete_mask 为 true 的记录。为了不影响MVCC的正常工作，purge 线程自己也维护了一个 read view（这个 read view 相当于系统中最老活跃事务的read view），如果某个记录的 delete_mask 为 1，并且 DB_TRX_ID 相对于 purge 线程的 read view 可见，那么这条记录一定是可以被安全清除的。

2.3 Read View

Read View 是用于记录每个事务开始时间的数据结构，以便 MySQL InnoDB 在查询时能够根据事务启动时间戳和各个数据行对应的版本链信息来确定该事务能够访问到哪些数据。

当一个事务开始执行时，MySQL InnoDB 会记录下该事务开始的时间戳。之后，在这个事务执行的过程中，如果需要读取某个数据行，MySQL引擎会根据这个时间戳和该数据行对应的版本链信息（Undo Log 链），找到最近的、在该事务启动时间之前已经提交的数据版本。这样，就可以保证在该事务的执行过程中，读取的数据是和该事务启动时一致的。

每次开启一个事务时，都会创建当前事务对应的 Read View。因此，不同的事务对同一行数据的读取结果可能是不同的，这取决于它们启动的时间。

Read View 包含多个字段，如下：

struct read_view_t{
	ulint								type;
	undo_no_t							undo_no;
	trx_id_t							low_limit_no;
	trx_id_t							low_limit_id;
	trx_id_t							up_limit_id;	
	ulint								n_trx_ids;
	trx_id_t*							trx_ids;
	trx_id_t							creator_trx_id;
	UT_LIST_NODE_T(read_view_t)			view_list;
}

其中比如重要的字段如下：

  • TRX_IDS：InnoDB 为每个事务构造了一个数组 trx_ids，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务 ID。（“活跃”指的就是，启动了但还没提交。）
  • LOW_LIMIT_ID：TRX_IDS 数组中的最小事务ID。
  • UP_LIMIT_ID：Read View 生成时刻系统尚未分配的下一个事务ID的值，也就是目前已出现过的事务ID的最大值+1。
  • CREATOR_TRX_ID：创建当前 Read View 的事务ID。

数组里面事务 ID 的最小值记为低水位(LOW_LIMIT_ID)，当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位(UP_LIMIT_ID)。这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。

低水位和高水位将事务分成了三段：

在这里插入图片描述

Read View 通过判断这四个字段的方式来确定哪些数据对于当前事务来说是可见的，哪些是不可见的。判断过程如下：

  • 如果 TRX_ID(当前事务id) 等于 CREATOR_TRX_ID，则说明当前事务在访问它自己修改过的记录，所以这个版本可以被当前事务访问。
  • 如果 TRX_ID 小于 LOW_LIMIT_ID，则说明在 Undo Log 版本链中这个事务在当前事务生产 Read View 前已经提交，所以这个版本可以被当前事务访问。
  • 如果 TRX_ID 大于或等于 UP_LIMIT_ID，说明在 Undo 版本链中的这个事务在当前事务生成 ReadView 后才开启，所以这个版本不可以被当前事务访问。
  • 如果 TRX_ID 在 LOW_LIMIT_ID 和 UP_LIMIT_ID 之间，此时再判断一下 TRX_ID 是不是在 TRX_IDS 列表中。
    • 如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问。
    • 如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

结论：

  • 修改当前行的事务提交了，数据才能被其他事务查看。
  • 每个事务只能看见其他事务已经提交了的数据修改。

2.4 MySQL MVCC

  1. 当一个事务开始时，它会获取一个唯一的事务ID（TRX_ID），并创建一个 Read View。
  2. 当事务执行插入、更新或删除操作时，数据库不会直接修改原始数据。相反，它会为每个修改操作创建一个新的数据版本，并将事务 TRX_ID 与新版本相关联（Redo Log 版本链）。原始数据行将保持不变。
  3. 对于读取操作，事务将会看到在其启动时间点之前已经提交的数据版本。这意味着事务不会看到其他事务尚未提交的数据更改。
  4. 当事务提交时，它的修改将被标记为已提交，并且其他事务将能够看到这些已提交的修改。
  5. 如果多个事务同时访问相同的数据行，每个事务都会看到不同的数据版本（通过 Read View 进行查看），这使得它们可以并发地读取和修改数据而不会相互干扰。
  6. 数据库通过 purge 线程定期清理已提交的旧数据版本，以避免存储空间被无用的数据占用。

三、事务ACID特性

事务具有以下四个特性：

  • Atomicity（原子性）：事务是一个不可分割的整体，要么全部执行，要么全部不执行。
  • Consistency（一致性）：一致性，值事务前后数据的完整性必须保持一致。
  • Isolation（隔离性）：事务之间是相互隔离。
  • Durability（持久性）：一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

MySQL InnoDB 是通过那些机制保证了事务的几个特性？

3.1 Atomicity

MySQL 事务的原子性通过 Undo Log 日志保证的，Undo Log 主要分为两种：

  • Insert Undo Log：记录 MySQL 进行 INSERT 时产生的 Undo Log。只需要在事务回滚时需要，事务提交后可立即删除。
  • Update Undo Log：记录 MySQL 进行 UPDATE、DELETE 时产生的 Undo Log。在事务回滚时需要，在快照读时也需要；不能立即删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被 purge 线程统一清理。

3.1.1 Insert Undo Log

之所以要分开，本质上是因为 Insert 操作只是为事务回滚做准备，不需要在 MVCC 中承担任何作用，因此只需要记录对应记录的 key 即可，结构如下：
在这里插入图片描述

  • Next Record Offset： 记录下一个 Undo Log 日志地址；
  • undo_type：日志类型，undo_type=TRX_UNDO_INSERT_REC，表示 insert 操作的 undo 日志类型；
  • undo_no：为 Undo Log 中递增编号，在一个事务汇总，从0开始递增；
  • table_id：记录当前操作表；
  • Key Fields：记录当前表的主键，用于在回滚时定位数据，多个的原因是可能存在联合主键，其中 Length 表示当前主键列占用的存储空间大小，Content 表示主键列的值；
  • prev record offset：记录上一个 Undo Log 日志地址；

数据表：

CREATE TABLE `user` (
	`id` BIGINT(20) NOT NULL,
	`name` VARCHAR(50) NOT NULL COMMENT '姓名',
	PRIMARY KEY (`id`) USING BTREE
)
;

对表 user 进行数据插入时，会向 Undo Log 中插入一条 TRX_UNDO_INSERT_REC 类型的日志，同时插入记录中的隐式字段 roll_pointer 会指向当前 Undo Log，如下：
在这里插入图片描述

3.1.2 Update Undo Log

Update Undo Log 中记录 delete 和 update 操作产生的 Undo Log。
Update Undo Log 涉及到 MVCC 的功能，所以 Update 操作需要保留 Record 的多个历史版本，当某个 Record 的历史版本还在被使用的时候，这个 Record 不能从 Undo Log 中真正删除，因此需要删除的时候，只是修改对应 Record 的 delete_mask 值。如果当前 Record 又被重新插入到 Undo Log 中，那么这个时候只需要修改 delete_mask 即可。

Update Undo Log 日志的清理会有专门的 purge 线程来清理 delete_mask 为 1 的记录，为了不影响MVCC的正常工作，purge 线程自己也维护了一个 read view（这个 read view 相当于系统中最老活跃事务的read view），purge线程清理条件如下：

  • 记录的 delete_mask 为 1；
  • 并且 DB_TRX_ID 相对于 purge 线程的 read view 可见，那么这条记录一定是可以被安全清除的；

Update Undo Log 结构如下：
在这里插入图片描述
与 Insert Undo Log 存在相同字段信息，除此之外，Update Undo Record增加了：

  • transaction_id：记录了产生这个历史版本事务Id，用作后续 MVCC 中的版本可见性判断；
  • roll_pointer：指向的是该记录的上一个版本的位置，沿着 roll_pointer 可以找到一个 Record 的所有历史版本;
  • Update Fields：记录当前这个 Record 版本修改的字段信息，包括所有被修改字段的编号，长度和历史值。

当一个事务对记录进行更新时，会把当前记录当做历史快照保存下来，形成一个历史版本链，当需要事务回滚时，可以依赖这个历史版本链将记录回滚到事务开始之前的状态，从而保证了事务的原子性。

在 Update Undo Log 中，Undo Log类型还细分为三种类型，如下：

  • Delete Undo Log：undo_type=TRX_UNDO_DEL_MARK_REC
  • Update Undo Log（更新主键）：undo_type=TRX_UNDO_DEL_MARK_REC
  • Update Undo Log（不更新主键）：undo_type=TRX_UNDO_DEL_MARK_REC
1. Delete Undo Log

当进行 delete 操作是，由于 MVCC 需要保留 Record 的多个历史版本，如果 Record 历史版本还在被使用时，那么这个 Record 不能真正被删除，所以在需要做删除操作时，只需要修改对应 Record 的 delete_mask 标记，并记录一条类型为 TRX_UNDO_DEL_MARK_REC 类型的 Undo 日志，实现原理如下。

在这里插入图片描述
在这里插入图片描述

2. Update Undo Log（更新主键）

如果涉及到主键的更新，在 Update 语句所在的事务提交之前，不会直接把旧的记录删除，因为有可能其他的事务要访问到这个记录（MVCC相关内容），所以需对旧记录的 delete_mask 更新为 1，然后根据更新后的各项值，创建一条新记录重新定位并插入到聚集索引中。

所以如果涉及主键更新，会生成两个 Undo Log 日志记录，如下：
在这里插入图片描述

3. Update Undo Log（不更新主键）

不更新主键的情况下，又可以分为更新的列占用的存储空间是否发生变化两种情况。

  1. 不发生变化， 表示更新的每个列，更新前后占用的存储空间不变， 那么直接可以在原记录进行修改。在不更新主键的这种情况且更新后的字段占用空间不变的情况下，向 Undo Log中添加的日志类型是TRX_UNDO_UPD_EXIST_REC，相比于其他类型，它会多出一些属性。
    • n_updated， 有多少个列被更新
    • 被更新的列更新前的信息
    • 如果更新的列包含索引列，则需要添加索引列的信息
  2. 发生变化， 如果被更新的字段，任意一列更新前后占用的存储空间 发生了变化，那么就不能直接在原来的记录上直接修改，而是需要先在聚集索引中删除这条记录，然后再根据更新后的值创建一条新记录。

注意，这里的删除，就不是像前面那样直接修改delete_mask， 而是由用户线程同步执行真正的删除，因为这里有锁的保护，并 不存在并发问题。

3.2 Durability

MySQL InnoDB 通过 Redo Log 和 Doublewrite Buffer Files 来保证数据的持久性。

  • Redo Log：Redo Log记录了每个事务所做的更改，包括 INSERT、UPDATE 和 DELETE 操作。Redo Log 的作用是在数据库崩溃或断电等情况下，能够通过重新执行重做日志中的操作来还原数据。这确保了已提交的事务在崩溃后不会丢失，并且数据保持一致。
  • Doublewrite Buffer Files：Doublewrite Buffer 是 InnoDB 存储引擎的一个缓冲区，用于写入数据页的备份副本。在将数据写入磁盘数据文件之前，InnoDB 首先将数据写入 Doublewrite Buffer，然后再写入磁盘数据文件。这样做的好处是，如果在写入磁盘数据文件时发生崩溃或错误，不会损坏数据页，因为有 Doublewrite Buffer 中的备份。这提供了额外的数据保护和一致性。
  • 在这里插入图片描述

3.3 Consistency

事务执行前后，数据库的状态必须保持一致。

3.4 Isolation

3.4.1 MySQL事务隔离级别

事务并发操作，要解决的数据一致性问题：

  • 脏读（Dirty Read）：指一个事务在读取了另一个事务未提交的数据。
  • 不可重复读（Non-repeatable Read）：指同一个事务内，同一数据行的多次读取返回了不同的结果。
  • 幻读（Phantom Read）：指在一个事务内，多次查询返回了不同数量的数据行（在事务执行期间，其他事务插入或删除了满足查询条件的数据行）。

MySQL事务隔离级别

  1. Read UnCommitted（RU，读未提交）：事务可以读取其他事务未提交的数据修改。这是最低级别的隔离，它允许脏读，不可重复读和幻读。这个级别的性能最高，但数据一致性最低。
    • 所有的操作都不会加锁。
  2. Read Committed（RC，读已提交）：事务只能读取其他事务已提交的数据修改。这可以避免脏读，但仍然允许不可重复读和幻影读。
    • 普通的 select 都采用快照读，使用 MVCC 实现。
    • 除了两种特殊情况——外键约束检查(foreign-key constraint checking)以及重复键检查(duplicatekey checking)时会使用Gap Locks-间隙锁（后面会详细分析）封锁区间，其他加锁的 select 都使用记录锁。
  3. Repeatable Read（RR，可重复读）：事务在开始时创建与之对应的一致性的快照（Read View），之后的查询都将基于 Read View 进行，因此不会出现不可重复读。但仍然允许幻影读。这是MySQL默认的事务隔离级别。
    • 普通的 select 都采用快照读，使用 MVCC 实现。
    • 加锁的select(select ... in share mode / select ... for update)以及更新操作 update, delete等语句使用当前读（current read），底层使用记录锁、或者 间隙锁、临键锁。
  4. Serializable（串行化）：要求事务完全串行执行，不允许并发操作。这可以避免脏读，不可重复读和幻读，但性能最低。
    • 所有的 select 语句都会被隐式的转化为 select ... lock in share mode， 会和update、delete互斥。

隔离级别从小到大为：

Read UnCommitted -> Read Committed -> Repeatable Read -> Serializable

性能与安全性之相反。

你可以使用以下 命令来查看和设置MySQL事务的隔离级别：

# 查看默认的全局隔离级别和当前 session 的隔离级别
# 查看 8.0前
SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
# 查看 8.0后
SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;
# 设置
SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED|READ COMMITTED|REPEATABLE READ|SERIALIZABLE]

需要注意的是，较高级别的隔离通常会导致更多的锁竞争和性能下降。因此，在选择隔离级别时，需要根据应用程序的需求和性能要求进行权衡。

3.4.2 MVCC如何解决RC

每次查询前都会生成一个独立的 ReadView。流程如下：
在这里插入图片描述
判断过程如下：

  • 如果 TRX_ID(当前事务id) 等于 CREATOR_TRX_ID，则说明当前事务在访问它自己修改过的记录，所以这个版本可以被当前事务访问。
  • 如果 TRX_ID 小于 LOW_LIMIT_ID，则说明在 Undo Log 版本链中这个事务在当前事务生产 Read View 前已经提交，所以这个版本可以被当前事务访问。
  • 如果 TRX_ID 大于或等于 UP_LIMIT_ID，说明在 Undo 版本链中的这个事务在当前事务生成 ReadView 后才开启，所以这个版本不可以被当前事务访问。
  • 如果 TRX_ID 在 LOW_LIMIT_ID 和 UP_LIMIT_ID 之间，此时再判断一下 TRX_ID 是不是在 TRX_IDS 列表中。
    • 如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问。
    • 如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

3.4.3 MVCC如何解决RR

只是在第一次查询前生成一个 ReadView，之后的查询都重复使用这个 ReadView。流程如下：
在这里插入图片描述

判断过程如下：

  • 如果 TRX_ID(当前事务id) 等于 CREATOR_TRX_ID，则说明当前事务在访问它自己修改过的记录，所以这个版本可以被当前事务访问。
  • 如果 TRX_ID 小于 LOW_LIMIT_ID，则说明在 Undo Log 版本链中这个事务在当前事务生产 Read View 前已经提交，所以这个版本可以被当前事务访问。
  • 如果 TRX_ID 大于或等于 UP_LIMIT_ID，说明在 Undo 版本链中的这个事务在当前事务生成 ReadView 后才开启，所以这个版本不可以被当前事务访问。
  • 如果 TRX_ID 在 LOW_LIMIT_ID 和 UP_LIMIT_ID 之间，此时再判断一下 TRX_ID 是不是在 TRX_IDS 列表中。
    • 如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问。
    • 如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

3.4.4 LBCC

除了MVCC，MySQL还提供了LBCC（Lock-Based Concurrency Control，基于锁的并发控制）的机制来实现事务的隔离特性。

基于锁的方式起始比较简单，就是一个事务在进行数据查询时，不允许其他事务修改，当前，这种方案在一定程度上影响了操作数据的率，所以对于怎么加锁、锁的范围和粒度 MySQL 进行了细的划分。

1. 锁的粒度
  • 行锁：只锁定当前操作数据行。
  • 表锁：锁定当前操作整个数据表。

在 MySQL 中，MyISAM 只支持表锁，InnoDB 支持行锁和表锁。

2. 锁的类型

在 MySQL 官网文档【InnoDB Locking】中有详细的说明，将锁分为 八类，如下：

  1. Shared and Exclusive Locks（共享锁 / 排它锁）：行级锁

  2. Intention Locks（意向锁）：表锁

  3. Record Locks（记录锁）：记录锁是索引记录上的锁，它封锁该行的索引记录，并不是真正的数据记录。
    如下：select * from user where id = 1 FOR UPDATE;，只会锁定 id=1 的记录。
    在这里插入图片描述

  4. Gap Locks（间隙锁）：顾名思义锁间隙，它锁定一段范围内的索引记录。 比如下面这个查询 select * from user where id between 1 and 4 FOR UPDATE，所有在 (1,4) 区间内的记录行都会被锁住，它是一个左右开区间的范围，只会锁住 id 为2，3的索引，但是1、4不会被锁定，如下图所示：
    在这里插入图片描述

  5. Next-Key Locks（临键锁）：Next-Key 可以理解为一种特殊的间隙锁，每个数据行上的非唯一索引列上都会存在一把临键锁，当某个事务持有该数据行的临键锁时，会锁住一段左开右闭区间的数据。
    假设存在如下一个数据表：

id(主键)age(普通索引)name
118张三
321李四
522王二
735小一

那么这个表中 age 列的潜在临键锁有（唯一索引列，包括主键列，上不存在临键锁）：（-∞，18] 、 （18，21]、（21，22]、（22，35]、（35，+∞]。假设事务执行下面命令：

UPDATE user SET name = '王五' WHERE age > 18;
SELECT * FROM user WHERE age > 18 FOR UPDATE;

不管执行上面的哪个SQL，当前事务都会锁定（18，21]这个区间。之后如果有另外一个事务来执行insert into user values(10, 19, '小三');命令会被阻塞，因为插入的数据 age=19，正好在锁定的区间。
为什么要锁住下一个左开右闭的区间？就是为了解决幻读的问题。

  1. Insert Intention Locks（插入意向锁）：一种特殊的间隙锁，用于协调多个事务同时在同一表上进行插入操作，避免在相同的范围内插入数据，从而减少了插入冲突的可能性。和间隙锁的关系：“Insert Intention Locks” 是间隙锁（Gap Locks）的一种形式。间隙锁用于锁定索引范围之间的间隙，以防止其他事务在这些间隙内插入新数据。 “Insert Intention Locks” 表明事务打算在特定的间隙内执行插入操作，因此它们与间隙锁有关。
  2. AUTO-INC Locks（自增锁）：是一种特殊的表锁，用来防止自增字段重复，数据插入以后就会释放，不需要等到事务提交才释放。
  3. Predicate Locks for Spatial Indexes（空间索引谓词锁）

在上面分析汇总，间隙锁和临键锁差不多，那什么情况下加临键锁，什么情况下加间隙锁呢？

当我们使用了范围查询，不仅仅命中了 Record 记录，还包含了 Gap间隙，在这种情况下我们使用的就是临键锁，它是MySQL里面默认的行锁算法，相当于记录锁加上间隙锁。

普通人zzz~
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
面试官问我MySQL事务的底层原理？幸亏我总结了全套八股文
一灯架构的专栏
06-17 655
面试开始，直入正题。面试官： 看你简历上面写着精通MySQL，我先问你事务的特性是什么？我： 这个我知道，事务有四大特性，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），简称ACID。原子性是指事务中所有操作要么全部成功，要么全部失败。一致性是指事务执行前后，数据始终处于一致性状态，不会出现数据丢失。隔离性是指事务提交前的中间状态对其他事务不可见，即相互隔离。持久性是指事务提交后，数据的修改永久保存在数据库中。面试官： 嗯，
Mysql底层原理与优化技巧
06-14
总的来说，掌握MySQL的底层原理，理解存储引擎的工作方式，善用索引，优化SQL，关注数据库设计，熟悉JDBC连接池的管理，并结合性能监控工具，是实现企业级MySQL优化的关键。通过不断学习和实践，你将能更好地驾驭这...
深入浅出MySQL事务实现底层原理
KDLin‘s Blog
05-26 998
在执行更新语句过程，会记录 redo log 与 binlog 两块日志，以基本的事务为单位，redo log 在事务执行过程中可以不断写入，而 binlog 只有在提交事务时才写入，所以 redo log 与 binlog 的写入时机不一样。大致描述一下我的理解：MySQL在开启事务的时候，会收集当前活跃的事务列表，于是它就可以通过事务ID，加上上边的多版本数据，去分析当前存在的数据变更，自己可见的是哪些，不可见的是哪些。但这里MVCC的方式，是每次读的时候，都会读取不同版本，这会造成不可重复读问题。
阿里面试：事务ACID，底层是如何实现的？
架构师尼恩
05-06 1254
事务（Transaction）是数据库管理系统执行过程中的一个逻辑单位，它由一个有限的数据库操作序列构成。事务（Transaction）是访问和更新数据库的程序执行单元；事务中可能包含一个或多个sql语句，这些语句要么都执行，要么都不执行。这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。事务的目的是确保数据的完整性和一致性，它通过一系列的操作，将数据库从一个一致性状态转换到另一个一致性状态。首先回顾一下MySQL事务的基础知识。
mysql事务底层原理
CrazyWorkers的博客
02-22 858
一、mysql逻辑架构 第一层：连接层，处理客户端连接，以及授权认证，安全检测。 第二层：服务器层，负责查询语句的解析，优化，缓存以及内置函数的实现、存储过程实现等 第三层：存储引擎层，负责mysql中数据的存储和提取，mysql事务是由存储引擎实现并管理的。 mysql支持事务的存储引擎有InnoDB,NDB Cluster等，InnoDB使用最为广泛。 二、mysql事务使用方法 start transaction;#事务开始的标识 ...#一条或多条sql语句 commit;#提交事务
MYSQL 事务的底层原理
京东科技开发者
11-16 118
一、事务的底层原理在事务的实现机制上，MySQL 采用的是 WAL：Write-ahead logging，预写式日志，机制来实现的。在使用 WAL 的系统中，所有的修改都先被写入到日志中，然后再被应用到系统中。通常包含 redo 和 undo 两部分信息。为什么需要使用 WAL，然后包含 redo 和 undo 信息呢？举个例子，如果一个系统直接将变更应用到系统状态中，那么在机器掉电重启之后系统...
MySQL事务底层实现原理
qq_40312909的博客
10-23 4915
事务特性 事务特性分为： 原子性 每一个事务都是不可分割的整体，要么全部成功要么全部失败； 一致性 事务执行后的结果是和预设的规则完全符合的，不会因为出现系统意外等原因和预测的结果不一致； 隔离性 事务与事务之间是相互独立的，互不影响；也是在事务并发时实现一致性的一个前提，可以设置4种隔离级别。级别越高一致性越强，但并发性越低； 1.读未提交 会读到其他事务未提交的数据，产生脏读 2.读已提交 解...
MySQL事务的底层实现原理
qq_40382400的博客
08-08 143
MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制，InnoDB的 MVCC ，是通过在每行记录的后面保存两个隐藏的列来实现的，这两个列，一个保存了行的创建时间，一个保存了行的过期时间，当然存储的并不是实际的时间值，而是系统版本号，他的主要实现思想是通过数据多版本来做到读写分离。MVCC在mysql中的实现依赖的是undo log与read view，undo log 中记录的是某行数据的多个版本的数据。原子性，持久性，隔离性的目的也是为了保障数据的一致性！
数据库MYSQL底层原理分析-笔记-pdf
05-15
3. **Mysql事务以及锁原理讲解**： - 事务（Transaction）是数据库操作的基本单位，保证了数据的一致性和完整性。MySQL支持四种事务隔离级别：读未提交（READ UNCOMMITTED）、读已提交（READ COMMITTED）、可重复读...
鲁班学员mysql底层原理分析学习笔记
03-01
这篇鲁班学院的MySQL底层原理分析学习笔记将深入探讨MySQL的核心机制，帮助读者理解数据存储、查询优化、事务处理以及并发控制等关键概念。 1. **存储引擎**：MySQL支持多种存储引擎，如InnoDB（事务安全，支持行级...
事务底层与高可用原理.md
05-23
事务底层与高可用原理.md
深入理解Spring事务原理
09-02
Spring事务管理是Spring框架的核心特性之一，它使得开发者能够在应用层面上轻松地处理数据库事务，无需直接接触底层的事务控制。本文将深入探讨Spring事务原理，包括事务的基本概念、Spring事务的传播属性、数据库...
MySQL事务原理
weixin_38170468的博客
11-22 106
原子性、稳定性和持久性实现原理 　　原子性、稳定性和持久性是通过redo 和 undo 日志文件实现的，不管是redo还是undo文件都会有一个缓存我们称之为redo_buf和undo_buf。同样，数据库文件也会有缓存称之为data_buf。 4.1 undo 日志文件 　　undo记录了数据在事务开始之前的值，当事务执行失败或者ROLLBACK时可以通过undo记录的值来恢复数...
Mysql 底层实现 事务
郭传志的博客
05-22 358
1、原子性 在同一个事务内部的一组操作必须全部执行成功（或者全部失败）。 为了保证事务操作的原子性，必须实现基于日志的REDO/UNDO机制：将所有对数据的更新操作都写入日志，如果一个事务中的一部分操作已经成功，但以后的操作，由于断电/系统崩溃/其它的软硬件错误而无法继续，则通过回溯日志，将已经执行成功的操作撤销，从而达到“全部操作失败”的目的。 最常见的场景是，数据库系统崩溃后重启，此时数据库处于不一致的状态，必须先执行一个crash recovery的过程：读取日志进行REDO（重演将所有已经执行成
MySQL底层事务实现的原理
li-zhang-yu的博客
03-27 144
一：MySQL底层事务实现的原理
【MySQL】MySQL的事务原理和实现？
DreamSun的博客
05-29 4578
什么是redo log?redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中。假设有个表叫做tb1(id,username) 现在要插入数据（3，ceshi）// 生成 重做日志 balance=600 update bank set balance = balance - 400;
【mysql】事务 运行原理 概述
u010900754的专栏
09-25 477
以前没有深究过数据库底层是怎么运作的，只是停留在了概念层次，但是后来发现写程序的时候不是很舒服，总感觉有些点不通，于是决定看看mysql innodb引擎的原理，这里只是一个大致的介绍，不会太深入。 如果我们在mysql的客户端执行了一些个操作，我们不了解任何底层，最简单的概念模型就是认为数据库的表里面的数据被修改了。也就是我这里执行一次update，数据库就会执行一个修改的io操作，很直观的理...
mysql事务的实现原理_mysql事务底层实现原理大解析
weixin_33253741的博客
01-19 432
四大特性事务具有ACID四个特性。也即：原子性，一致性，隔离性，持久性。原子性：语句要么全执行，要么全不执行，是事务最核心的特性，事务本身就是以原子性来定义的；实现主要基于undo log持久性：保证事务提交后不会因为宕机等原因导致数据丢失；实现主要基于redo log隔离性：保证事务执行尽可能不受其他事务影响；InnoDB默认的隔离级别是RR，RR的实现主要基于锁机制、数据的隐藏列、undo l...
mysql事务隔离性底层原理
最新发布
07-03
MySQL事务的隔离性是数据库管理系统保证数据一致性的重要机制。其底层原理主要依赖于ACID（原子性、一致性、隔离性、持久性）原则中的隔离级别来实现。MySQL支持四种标准的隔离级别： 1. **读未提交（READ UNCOMMITTED）**：最低的隔离级别，事务可以读取其他事务未提交的数据，可能导致脏读（看到的是不完整或错误的数据）。 2. **读已提交（READ COMMITTED）**：事务只能看到已经提交的数据，解决了脏读的问题，但可能仍存在幻读（同一查询结果在两次并发操作后不同）和不可重复读（对某行的多次读取得到不同值）。 3. **可重复读（REPEATABLE READ）**：在此级别上，事务在其整个生命周期内不会看到其他事务对其未提交的更改，避免了幻读，但仍然存在不可重复读的问题。 4. **串行化（SERIALIZABLE）**：最高的隔离级别，强制所有的事务看起来像是顺序执行，完全避免了幻读和不可重复读，但性能开销最大。 MySQL通过锁定机制（行级锁、页级锁、表级锁等）以及Latching（乐观锁或悲观锁）来控制对数据的访问，根据隔离级别的不同调整锁定策略。当两个事务并发操作时，MySQL会基于当前事务的隔离级别决定如何管理锁定，从而确保满足所选择的隔离级别下的数据一致性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值