MySQL 的事务隔离级别

在 MySQL 8.0 Reference Manual 中描述了 InnoDB 的事务隔离介绍： > InnoDB 提供了 SQL-92 标准中描述的所有 4 种隔离级别的支持，它们是：READ UNCOMMITTED，READ COMMITTED，REPEATABLE READ，和 SERIALIZABLE。InnoDB 的默认隔离级别为 REPEATABLE READ。

本文是对 《Spanner: Google’s Globally-Distributed Database》的翻译，原文请见：https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf

摘要

Spanner 是 Google 的可伸缩、多版本、全球分布且同步复制的数据库。它是首个在全球范围分布数据且支持外部一致性分布式事务的系统。本文描述了 Spanner 的结构、特性集、其多项设计决策下蕴含的理论基础以及一个能够暴露时钟不确定性（clock uncertainly）的新颖的时间 API。该 API 及其实现是作为关键角色来支撑外部一致性和其他许多涉及整个 Spanner 的强大特性，如对过往数据的非阻塞读（nonblocking read in the past），无锁的读事务，原子的 schema 变更等。

这一节的主要内容，是讲解 TiKV 如何执行下推计算的。

本文中涉及到的图片来源，都来自 PingCAP 官方网站。

通过先前的课程我们了解到，tidb 在生成执行计划时，先生成逻辑计划，之后将逻辑计划翻译成物理计划。而物理计划最终都是以 task 的形式来执行的，task 分 root task 和 coptask，coptask 通常就会下推至 tikv 来执行。

本节课程主要学习的是 TiDB 的 事务原理。由于 TiDB 的分布式部署的特性，其事务的实现主要借鉴了 Percolator 中分布式事务的实现方式，将 TiDB 与 TiKV 结合起来，共同完成分布式事务的任务。

本文中涉及到的图片来源，都来自 PingCAP 官方网站。

本节课程主要学习的是 TiDB 的 planer 模块，planer 模块的主要功能是将 AST 转化为实际的执行计划，在这当中，包含了两个阶段的优化过程：逻辑优化、物理优化。优化过后的执行计划可以直接构造对应的 Executor 来执行（回忆 Executor 章节的火山模型）。

本文中涉及到的图片来源，都来自 PingCAP 官方网站。

这一节，我们涉及的知识是 TiDB 如何实现 DDL。

本次课程主要涉及 TiDB 中的 Executor 组件。

本节课程作业，我们会采用多种 profile 工具来对 TiDB 的性能进行分析，寻找其性能瓶颈，并根据分析结果来给出优化建议。

主要内容如下：

1. TiUP 部署最小集群
2. TiDB CPU Profile
3. 性能瓶颈分析与优化建议

这一节，我们需要对一个完整的 TiDB 集群进行性能测试，为了实现这一目标，本文会通过以下几个步骤来介绍如何从零开始实现 TiDB 的性能测试：

1. 借助 kind 在单机模拟集群
2. 通过 TiDB Operator 部署 TiDB 集群到 K8S
3. 根据机器硬件调整 TiDB 配置
4. 性能测试
   1. sysbench 测试
   2. go-ycsb 测试
   3. go-tpc 测试
5. 性能瓶颈分析

今年了解到 TiDB 这样一个 HTAP 数据库，在 Github 上面热度超高，再加上国人开发与维护，因此产生了很大的兴趣。

正好社区搞了一个《高性能 TiDB 课程学习计划》通过 12 节课来使学员能达到 Committer 的水平，因此就报名参加啦。

第一节课的课程作业是尝试在本地启动一个最小集群，并在开启事务时打印 “hello transaction” 并将这一过程写成一片文章，因此本文将会主要描述这一过程。