diff --git a/session3/chapter5/recover-statements.md b/session3/chapter5/recover-statements.md
index 3f1719dc63..391fe4cf8d 100644
--- a/session3/chapter5/recover-statements.md
+++ b/session3/chapter5/recover-statements.md
@@ -1,10 +1,10 @@
-## 5.2 利用 Recover/Flashback 命令秒恢复误删表
+## 5.2 利用 Recover/Flashback 命令快速恢复误删表
 
-对于 DBA 来说，删库跑路永远是被调侃的哏，近在眼前的某微商平台的大面积宕机事件给企业管理人员及数据库运维团队带来的启示仍在被不断讨论。当然为了应对大面积的恶意删库跑路行为，可能真的是防不胜防，不过这种情况也非常罕见。但是大家尤其是线上运维 DBA 在维护数据库的过程中，出现删错表/库的情况却是很容易出现的，下面来看一下 TiDB 提供的快速恢复误删表的功能。
+对于 DBA 来说，删库跑路永远是被调侃的梗，近在眼前的某微商平台的大面积宕机事件给企业管理人员及数据库运维团队带来的启示仍在被不断讨论。当然为了应对大面积的恶意删库跑路行为，可能真的是防不胜防，不过这种情况也非常罕见。但是大家尤其是 DBA 在维护数据库的过程中，出现误删表/库的情况却是很容易出现的，下面来看一下 TiDB 提供的快速恢复误删表的功能。
 
 ### 5.2.1 Recover 实现原理
 
-TiDB 在删除表时，实际上只删除了表的元信息，并将需要删除的表数据（行数据和索引数据）写一条数据到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 会定期从 mysql.gc_delete_range 表中取出超过 GC lifetime 相关范围的 key 进行删除。
+TiDB 在删除表时，实际上只删除了表的元信息，并将需要删除的表数据（行数据和索引数据）的 Key 范围写一条记录到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 会定期从 mysql.gc_delete_range 表中取出超过 GC lifetime 相关范围的 key 进行删除。
 
 所以，RECOVER TABLE 只需要在 GC Worker 还没删除表数据前，恢复表的元信息并删除 mysql.gc_delete_range 表中相应的行记录就可以了。恢复表的元信息可以用 TiDB 的快照读实现，TiDB 中表的恢复是通过快照读获取表的元信息后，再走一次类似于 CREATE TABLE 的建表流程，所以 RECOVER TABLE 实际上也是一种 DDL。
 
@@ -120,7 +120,7 @@ MySQL [test]> ADMIN SHOW DDL JOBS;
 +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 ```
 
-从 DDL 记录可以看到，我们一共执行了 2 次 drop table t2 的操作，如果只执行 recover table t2 恢复的是最近一次删除的表。如果我希望恢复前面一次删除的动作，就需要用到下面的命令
+从 DDL 记录可以看到，我们一共执行了 2 次 drop table t2 的操作，如果只执行 recover table t2，恢复的是最近一次删除的表。如果我希望恢复前面一次删除的动作，就需要用到下面的命令
 ```
 
 MySQL [test]> recover table by job 70;