doc: 阅读mysql mvcc文档

This commit is contained in:
asahi
2025-08-13 22:55:44 +08:00
parent b90bb79459
commit dcafbb38d8

View File

@@ -1,3 +1,17 @@
- [mysql mvcc](#mysql-mvcc)
- [Internal Impl](#internal-impl)
- [undo log](#undo-log)
- [insert undo log](#insert-undo-log)
- [update undo log](#update-undo-log)
- [commit regularly](#commit-regularly)
- [purge](#purge)
- [insert and delete rows in smallish batches](#insert-and-delete-rows-in-smallish-batches)
- [purge lag](#purge-lag)
- [innodb\_purge\_threads](#innodb_purge_threads)
- [innodb\_max\_purge\_lag](#innodb_max_purge_lag)
- [Multi-Versioning and Secondary Indexes](#multi-versioning-and-secondary-indexes)
# mysql mvcc
innodb是一个`多版本`的存储引擎对于被修改的records其保存了records旧版本的信息从而支持事务的`并发``回滚`等特性。
@@ -68,4 +82,13 @@ purge操作在后台由一个或多个purge threads执行。purge threads的数
当辅助索引的column被更新时旧的辅助索引记录将会被标记为delete marked并且插入新的辅助索引记录。`delete marked index records`最终会被purge。
当辅助索引中的index record被`delete marked``辅助索引页被newer transaction(更新的事务)更新时innodb将会在聚簇索引中查询记录`
当辅助索引中的index record被`delete marked``辅助索引页被newer transaction(更新的事务)更新时innodb将会在聚簇索引中查询记录`在聚簇索引中该record的DB_TRX_ID将会被检查查看并且会通过undo log构建出当前线程可见的数据版本。
> 行数据的版本记录存储在聚簇索引中。如果innodb在查找记录索引时发现该辅助index record被delete marked此时并不确定delete marked的操作是否对查询事务可见需要在聚簇索引中查找记录并构建历史版本。
>
> 当辅助索引页被newer transaction更新时也无法确定该辅助索引页中的内容是否对当前事务可见同样需要查询聚簇索引来构建先前的历史版本。
> 如果当前事务初始化后record才被其他事务修改那么根据事务的一致性读原则record的修改不应对当前事务可见需要通过record对应的undo log内容还原到数据的旧版本。
> 如果`当前辅助索引中的数据被delete marked`或`当前辅助索引页被newer transaction所更新`,那么`covering index`技术将不会被使用。故而并不会直接从辅助索引中返回值innodb而是会再次从clustered index中查询记录。