目录：

先说结论：不一定是。

可以分为三种场景：

1. 场景分析

1.1 不更新主键

1.1.1 就地更新（in-place update）

更新记录时，对于被更新的每个列来说， 如果更新后的列和更新前的列占用的存储空间都一样大 ，那么就可以进行 就地更新 （in-place update），也就是直接在原记录的基础上修改对应列的值。

1.1.2 先删除掉旧记录，再插入新记录

在不更新主键的情况下， 如果有 任何一个 被更新的列更新前和更新后占用的存储空间大小不一致 ，那么就需要先把这条旧的记录从聚簇索引页面中删除掉，然后再根据更新后列的值创建一条新的记录插入到页面中。

请注意（事务提交后）： 我们这里所说的 删除 并不是 delete mark 操作，而是真正的删除掉，也就是把这条记录从 正常记录链表 中移除并加入到 垃圾链表 中。加入到垃圾链表的过程并不是另外的purge线程处理的，而是由用户线程同步执行真正的删除（purge）操作。真正删除后紧接着就要根据各个列更新后的值创建新纪录插入。

这里如果新创建的记录占用的存储空间大小不超过旧记录占用的空间，那么可以直接重用被加入到 垃圾链表 中的旧记录所占用的存储空间，否则的话需要在页面中新申请一段空间以供新记录使用，如果本页面内已经没有可用的空间的话，那就需要进行页面分裂操作，然后再插入新记录。

1.2. 更新主键

在聚簇索引中，记录是按照主键值的大小连成了一个单向链表的，如果我们更新了某条记录的主键值，意味着这条记录在聚簇索引中的位置将会发生改变，比如你将记录的主键值从1更新为10000，如果还有非常多的记录的主键值分布在 1 ~ 10000 之间的话，那么这两条记录在聚簇索引中就有可能离得非常远，甚至中间隔了好多个页面。针对 UPDATE 语句中更新了记录主键值的这种情况， InnoDB 在聚簇索引中分了两步处理：

高能注意： 这里是delete mark操作！这里是delete mark操作！这里是delete mark操作！ 也就是说在 UPDATE语句所在的事务提交前，对旧记录只做一个 delete mark 操作， 在事务提交后才由专门的线程做purge操作，把它加入到 垃圾链表 中 。这里一定要和我们上边所说的在不更新记录主键值时，先真正删除旧记录，再插入新记录的方式区分开！

之所以只对旧记录做delete mark操作，是因为别的事务同时也可能访问这条记录，如果把它真
正的删除加入到垃圾链表后，别的事务就访问不到了。这个功能就是所谓的MVCC，

由于更新后的记录主键值发生了改变，所以需要重新从聚簇索引中定位这条记录所在的位置，然后把它插进去。

针对 UPDATE 语句更新记录主键值的这种情况，在对该记录进行 delete mark 操作前，会记录一条类型为TRX_UNDO_DEL_MARK_REC 的 undo日志 ；之后插入新记录时，会记录一条类型为TRX_UNDO_INSERT_REC 的 undo日志 ，也就是说每对一条记录的主键值做改动时，会记录2条 undo日志 。

2. 附录：

2.1 delete操作的两个阶段

我们知道插入到页面中的记录会根据记录头信息中的 next_record 属性组成一个单向链表，我们把这个链表称之为 正常记录链表 。
被删除的记录其实也会根据记录头信息中的 next_record 属性组成一个链表，只不过这个链表中的记录占用的存储空间可以被重新利用，所以也称这个链表为 垃圾链表 。 Page Header 部分有一个称之为 PAGE_FREE 的属性，它指向由被删除记录组成的垃圾链表中的头节点。

假设此刻某个页面中的记录分布情况是这样的（这个不是 undo_demo 表中的记录，只是我们随便举的一个例子）：

为了突出主题，在这个简化版的示意图中，我们只把记录的 delete_mask 标志位展示了出来。从图中可以看出， 正常记录链表 中包含了3条正常记录， 垃圾链表 里包含了2条已删除记录，在 垃圾链表 中的这些记录占用的存储空间可以被重新利用。

页面的 Page Header 部分的 PAGE_FREE 属性的值代表指向 垃圾链表 头节点的指
针。假设现在我们准备使用 DELETE 语句把 正常记录链表 中的最后一条记录给删除掉，其实这个删除的过程需要经历两个阶段：

阶段一：delete_mark阶段

可以看到， 正常记录链表 中的最后一条记录的 delete_mask 值被设置为 1 ，但是并没有被加入到 垃圾链表 。此时这条记录处于一个中间状态。在删除语句所在的事务提交之前，被删除的记录一直都处于这种所谓的 中间状态 。

ps：为啥会有这种奇怪的中间状态呢？其实主要是为了实现一个称之为MVCC的功能。

阶段二：purge阶段