InnoDB Multi-Versioning

2017-10-18, 2623 Words, 6 Minutes

InnoDB Multi-Versioning

InnoDB Multi-Versioning

InnoDB是一个多版本的存储引擎,他通过保存被修改的行的老版本来支持事务的特性,例如并发与回滚。这些信息存储在表空间里被叫做回滚段的数据结构中。InnoDB使用回滚段中的信息来执行事务回滚中必要的回滚操作。这些信息也被使用在一致性读取的时候创建数据的早期版本(与隔离级别有关)。

在内部,InnoDB为存储在数据库中的每一行添加三个条目。一个6字节的DB_TRX_ID标识最后一个事务的插入和更新,删除操作在内部被视为更新操作,在该行中的一个特殊的位被设置用来标识行被删除。每行还包含一个7字节的DB_ROLL_PTR滚动指针。这个滚动指针指向被写在回滚段中的一条Undo log记录。如果行被更新,Undo log中的这条记录在行被更新之前必须要重建内容(这里的意思是:在事务提交之前,即使行被改变也不会改变指针指向的Undo log记录,因为其他的事务可能访问该行原始的信息,需要从Undo log返回;在当前事务提交的时候,Undo log必须先更新,这样能保证之后的事务正常访问数据)。还有一个6字节的DB_ROW_ID,他包含一个行ID,在有新行插入的时候增加。如果InnoDB自动生成聚簇索引,那么索引也会包含这个ID值,否则DB_ROW_ID不会出现在任何索引中。

在回滚段中的Undo logs被分为插入Undo logs和更新Undo logs。插入Undo logs只在事务被回滚的时候使用,当事务提交就被丢弃。更新Undo log也被使用在一致性读取上,仅在没有事务的情况下被丢弃,InnoDB指定一个镜像,这个镜像包含在一致性读取中可能需要的更新Undo log创建的数据行的早期版本。

回滚段中的Undo log物理空间大小一般比相应插入或更新的行小。你可以通过这些信息计算你的回滚段需要的空间大小。

在InnoDB多版本模式下,执行删除语句不会立即物理删除数据库中的行。仅当因为删除操作写入更新undo log日志里面的记录被丢弃的时候,InnoDB会物理删除相应的行和索引记录。这种删除操作称为purge,他是非常快的,通常与执行删除操作的时间顺序相同。

如果一张表有同样概率的小批量插入和删除,由于所有的‘dead’行,making everything disk-bound(大概是:使所有的已标记为删除的行对应到更新Undo log都是跳跃的,不连续的),并且非常慢,这时候purge会开始落后,并且表会变的越来越大。在这种情况下,需要控制新行的插入,并且需要通过调节innodb_max_purge_lag系统变量来为pruge线程分配更多资源。

多版本与辅助索引

InnoDB多版本并发控制与聚簇索引对待辅助索引是不同的,在聚簇索引中的记录会立即更新,他们的系统隐藏列指向Undo log里面这个列的能被重建的早期版本。不像聚簇索引,辅助索引不包含系统隐藏列,也不会被立即更新。

当一个辅助索引列被更新,老的辅助索引列被标记为删除,新的纪录被插入,被标记为删除的记录最终会被purge。当辅助索引被标记为删除或被一个新的事务更新,InnoDB通过聚簇索引查找数据。在聚簇索引上,如果记录在读事务开始之后被修改,记录的DB_TRX_ID被检查,正确版本的记录会从Undo log返回。

如果辅助索引记录被标记为删除或者被新的事务更新,那么覆盖索引技术不能使用。取而代之的是从索引结构返回数据,InnoDB从聚簇索引中重找记录。

然而,如果index condition pushdown(ICP)优化被启用,where条件会被索引中单独的列进行评估,MySQL服务始终将这部分where条件推到存储引擎层面,在这里使用索引进行评估。如果没有记录被匹配,聚簇索引扫描就被避免了。如果有记录被匹配,被标记为删除的记录也算,InnoDB通过聚簇索引查找记录。

下面是相关知识点的具体介绍:

Undo logs

Undo log是与单个事务相关的Undo log记录的集合。Undo log记录包含如何从最新变更撤销到聚簇索引记录(指的是之前的数据库记录)的信息。 如果其他的事务需要查询原始数据(作为一致性读取的一部分),未修改的数据从Undo log返回。

聚簇索引

聚簇索引是主键索引的InnoDB术语,InnoDB表的存储是基于主键值进行组织的(索引组织表),用来加速涉及到主键的查询和排序。为了更好的性能,应该基于最关键的查询认真的选择索引。因为更改聚簇索引列是昂贵的操作,所以选择主键列rarely或者不进行更新。

辅助索引

InnoDB索引的一种类型,代表了表列的子集。InnoDB表可以没有也可以有一个或多个辅助索引(聚簇索引每个表是必须的,并且存储了表中所有列的数据)。 辅助索引满足仅需要被索引列的值的查询。对于更复杂的查询,他能被用来确定表中相关的行,然后通过查询聚簇索引返回数据。 以往,创建和删除辅助索引涉及到复制数据的大量开销。现在的fast index creation特性使CREATE INDEX和DROP INDEX语句执行的更快。

聚簇索引与辅助索引

每个InnoDB表都有一个特殊的索引叫聚簇索引,他上面存储了每一行的数据。通常聚簇索引是主键索引的同义词。为了从查询、插入以及其他操作中获得更好的性能,你必须知道InnoDB是如何使用聚簇索引去优化每张表的查询和DML操作的。

  • 当你在InnoDB表上定义了主键,这个列就被作为聚簇索引。为每个你创建的表定义主键。如果你的表没有唯一的、非空的列,那么添加一个新的自增列,它的值会被自动添加上。
  • 如果你的表没有定义主键,MySQL会定位第一个UNIQUE的列(并且不能为空),InnoDB会使用它作为聚簇索引。
  • 如果表没有主键,也没有合适的UNIQUE列,InnoDB会在内部生成一个包含行ID的虚拟列。数据行通过ID列排序。这个ID是一个6字节的区域,当有新行插入的时候单调递增。因此, 数据行的顺序就是物理层面数据的插入顺X序。

聚簇索引如何加速查询

通过聚簇索引访问行是非常快的,因为索引搜索直接指向包含所有行数据的页。如果表非常大,聚簇索引的架构通常更省磁盘I/O(索引条目指向的行存储在不同的页)。

辅助索引与聚簇索引的关系

除了聚簇索引的其他索引都被叫做辅助索引。在InnoDB中,当列被指定为辅助索引的时候,在辅助索引中的每条记录都包含当前行的主键索引,InnoDB使用主键值搜索在聚簇索引上的行。 如果主键太长,那么相应的辅助索引也会占用更多的空间。所以一个短的主键是有好处的。

(完)


Next:
Prev: