公众号和网站ps里面怎么做网站对联广告

MySQL MVCC 详解

维基百科上关于 MVCC 的介绍：

多版本并发控制(Multiversion concurrency control， MCC 或 MVCC)，是数据库管理系统常用的一种并发控制，也用于程序设计语言实现事务内存。
MVCC意图解决读写锁造成的多个、长时间的读操作饿死写操作问题。每个事务读到的数据项都是一个历史快照，并依赖于实现的隔离级别。写操作不覆盖已有数据项，而是创建一个新的版本，直至所在操作提交时才变为可见。快照隔离使得事务看到它启动时的数据状态。

MVCC 的核心是 “数据多版本”，即同一数据在系统中可以存在多个版本，每个事务看到的数据是特定版本的快照。具体来说：

• 读操作：无需加锁，直接读取数据的某个历史版本，避免了与写操作的冲突。
• 写操作：只锁定当前操作的数据，不影响其他事务的读操作。

这种机制使得读写操作可以并发执行，大大提高了数据库的并发性能。

MVCC 实现机制

MySQL中，MVCC的实现基于以下基石：

隐藏字段

InnoDB 中，每一行数据除了我们定义的字段外，还会存在一些额外的隐藏列：

• DB_TRX_ID：事务ID，表示插入或更新该行的最后一个事务的事务标识符；
• DB_ROLL_PTR：回滚指针，回滚指针指向写入回滚段的 undo log 记录；
• DB_ROW_ID：行ID，随着新行插入而单调增加。

事务ID

每次启动一个事务，InnoDB 会为其分配一个唯一递增的事务 ID。事务 ID 用于判断数据版本的可见性。

回滚段（Rollback Segment）与 undo 日志

当数据被修改时，InnoDB 会将旧数据复制到回滚段中，并通过DB_ROLL_PTR指针链接到 undo 日志。这些历史版本数据用于支持事务回滚和 MVCC 的读操作。

Read View（读视图）

每个读操作启动时会生成一个 Read View，包含当前活跃事务的列表。Read View 用于判断事务能看到哪些数据版本。Read View 包含以下四个关键属性：

• creator_trx_id：当前创建 Read View 的事务 ID。用于标识生成该 Read View 的事务。
• trx_ids：活跃事务列表，创建 Read View 时，当前所有未提交的事务 ID 列表（即活跃事务）。这些事务的修改对当前 Read View 可能不可见，需要根据规则判断。
• low_limit_id：创建 Read View 时，系统中已分配的最大事务 ID + 1。表示大于等于该值的事务 ID 在 Read View 创建后生成，对当前 Read View 不可见。
• low_limit_no：删除版本号：用于判断行的删除操作是否对当前事务可见（与 purge 操作相关）。核心是前三个属性。

对于读已提交事务隔离级别，在事务中每次执行查询都会重新创建一次Read View，因此可能会读取到其它事务提交的数据。
对于可重复读事务隔离级别，在事务中只会创建一次Read View，后续每次查询都使用第一次创建的Read View，因此保证了每次读取的数据都是一致的。

流程

• 数据准备，当前事务隔离级别为 读已提交

  create table t1 (id int primary key, c2 int);
  insert into t1 values (1, 100);
  

• 事务1

  START TRANSACTION;
  update t1 set c2 = 200 where t1 = 1;
  

• 事务2 开启并进行查询

  START TRANSACTION;
  select * from t1 where id = 1;
  

• 事务3

  START TRANSACTION;
  update t1 set c2 = 300 where t1 = 1;
  

• 事务2第二次次查询

  select * from t1 where id = 1;
  

• 事务1提交

  COMMIT;
  

• 事务2第三次查询

  select * from t1 where id = 1;
  commit;
  

假设上述事务1的事务ID=120，事务2的事务ID=130，事务3的事务ID=140。

对于事务2第一次查询时，事务1先一步开启进行数据修改，并且没有提交，MVCC 的处理流程如下：

1. 生成 Read View：
   • creator_trx_id：事务 2 的 ID = 130。
   • trx_ids：活跃事务列表，包含事务 1，为 120。
   • low_limit_id：创建 Read View 时，系统中已分配的最大事务 ID + 1 ，假定为131。
2. 查询操作获取到最新行中的 DB_TRX_ID=120，为事务1修改
3. 可见性判断：
   • 120 在 trx_ids 中，因此当前数据未提交，对于当前事务不可见；
   • 根据DB_ROLL_PTR查找undo log，事务ID为110，未被其它事务修改，数据可见；
4. 因此事务2第一次查询结果为 100。

对于事务2第二次查询时，新开启了事务3修改了数据，并且也没有提交，MVCC 的处理流程如下：

1. 生成 Read View：
   • creator_trx_id：事务 2 的 ID = 130。
   • trx_ids：活跃事务列表，包含事务1，事务3，为 120，140。
   • low_limit_id：创建 Read View 时，系统中已分配的最大事务 ID + 1，假定为141。
2. 查询操作获取到最新行中的 DB_TRX_ID=140，为事务3修改；
3. 可见性判断：
   • 140 在 trx_ids 中，因此当前数据未提交，对于当前事务不可见；
   • 根据DB_ROLL_PTR查找undo log，事务ID为120，仍然在 trx_ids 中，被事务1修改，对于当前事务不可见；
   • 继续根据DB_ROLL_PTR查找undo log，事务ID为110，未被其它事务修改，数据可见；
4. 因此事务2第二次查询结果为 100。

对于事务3第三次查询时，事务1提交，事务3仍然开启，MVCC 的处理流程如下：

1. 生成 Read View：
   • creator_trx_id：事务 2 的 ID = 130。
   • trx_ids：活跃事务列表，由于事务1已提交，因此只包含事务3，为140。
   • low_limit_id：创建 Read View 时，系统中已分配的最大事务 ID + 1，假定为141。
2. 查询操作获取到最新行中的 DB_TRX_ID=140，为事务3修改；
3. 可见性判断：
   • 140 在 trx_ids 中，因此当前数据未提交，对于当前事务不可见；
   • 根据DB_ROLL_PTR查找undo log，事务ID为120，事务已提交，数据可见；
4. 因此事务2第二次查询结果为 200。