TiDB 事务的实现采用了 MVCC（多版本并发控制）机制，当更新/删除数据时，不会做真正的数据删除，只会添加一个新版本数据，并以时间戳来区分版本。当然历史数据不会永久保留，超过一定时间的历史数据将会被彻底删除，以减小空间占用，同时避免因历史版本过多引起的性能开销。

TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行清理，默认情况下每 10 分钟一次。每次 GC 时，TiDB 会计算一个称为 safe point 的时间戳（默认为上次运行 GC 的时间减去 10 分钟），接下来 TiDB 会在保证在 safe point 之后的快照都能够读取到正确数据的前提下，删除更早的过期数据。

TiDB 的 GC 相关的配置存储于 mysql.tidb 系统表中，可以通过 SQL 语句对这些参数进行查询和更改：

例如，如果需要将 GC 调整为保留最近一天以内的数据，只需执行下列语句即可：

注意: TiDB 的事务是通过 PD 进行全局授时，所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot 时，是以 tidb_snapshot 变量的值作为版本号，如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大，需要以 PD 的时间为准。

当读取历史版本数据操作结束后，可以结束当前 Session 或者是通过 Set 语句将 tidb_snapshot 变量的值设为 “”，即可读取最新版本的数据。

1.初始化阶段，创建一个表，并插入几行数据：

create table t (c int);
Query OK, 0 rows affected (0.01 sec)
insert into t values (1), (2), (3);
Query OK, 3 rows affected (0.00 sec)

2.查看表中的数据：

select * from t;
+------+
| c    |
+------+
|    1 |
|    3 |
+------+

3.查看当前时间：

4.更新某一行数据：

update t set c=22 where c=2;
Query OK, 1 row affected (0.00 sec)

5.确认数据已经被更新：

select * from t;
+------+
| c    |
+------+
|    1 |
|   22 |
|    3 |
+------+
3 rows in set (0.00 sec)

6.设置一个特殊的环境变量，这个是一个 session scope 的变量，其意义为读取这个时间之前的最新的一个版本。

set @@tidb_snapshot="2016-10-08 16:45:26";

这里读取到的内容即为 update 之前的内容，也就是历史版本：

Query OK, 0 rows affected (0.00 sec)
select * from t;
+------+
| c    |
+------+
|    1 |
|   22 |
|    3 |
+------+
3 rows in set (0.00 sec)

注意： 在 tidb_snapshot 前须使用 @@ 而非 @，因为 @@ 表示系统变量，@ 表示用户变量。

通过读取历史数据可以快速恢复被更新/删除的数据，大致步骤如下：

1、调整 GC 保留时间，如将 GC 调整为保留最近一天以内的数据。

update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_time";

说明： 具体保留多长时间，需要结合业务进行评估

2、创建一个与待恢复的数据表同结构的临时表，如：

set @@tidb_snapshot="2016-10-08 16:45:26";

3、按照业务逻辑将需要的数据插入到临时表：

4、按照业务逻辑将数据从临时表反更新或插入到原表

5、按照业务逻辑校验数据

6、将 GC 保留时长调整为恢复之前的设置