From 12a4e32429dd02342481676369a3dcc0124d21c6 Mon Sep 17 00:00:00 2001 From: you06 Date: Fri, 13 Aug 2021 12:00:52 +0800 Subject: [PATCH 1/3] update transaction doc Signed-off-by: you06 --- optimistic-transaction.md | 2 +- transaction-isolation-levels.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 22c5cd010328..9dba3f7b2330 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -64,7 +64,7 @@ summary: 了解 TiDB 的乐观事务模型。 ## 事务的重试 -使用乐观事务模型时，在高冲突率的场景中，事务容易发生写写冲突而导致提交失败。MySQL 使用悲观事务模型，在执行 SQL 语句的过程中进行加锁并且其 Repeatable Read 隔离级别允许出现不可重复读，所以提交时一般不会出现异常。为了降低应用改造难度，TiDB 提供了数据库内部自动重试机制。 +使用乐观事务模型时，在高冲突率的场景中，事务容易发生写写冲突而导致提交失败。MySQL 使用悲观事务模型，在执行写入类型的 SQL 语句的过程中进行加锁并且在 Repeatable Read 隔离级下增加了当前读的机制，所以提交时一般不会出现异常。为了降低应用改造难度，TiDB 提供了数据库内部自动重试机制。 ### 重试机制 diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index 2bab7eea8c80..6b70c61564a9 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -49,7 +49,7 @@ commit; | ### 与 MySQL 可重复读隔离级别的区别 -MySQL 可重复读隔离级别在更新时并不检验当前版本是否可见，也就是说，即使该行在事务启动后被更新过，同样可以继续更新。这种情况在 TiDB 会导致事务回滚，导致事务最终失败，而 MySQL 是可以更新成功的。MySQL 的可重复读隔离级别并非 Snapshot 隔离级别，MySQL 可重复读隔离级别的一致性要弱于 Snapshot 隔离级别，也弱于 TiDB 的可重复读隔离级别。 +MySQL 可重复读隔离级别在更新时并不检验当前版本是否可见，也就是说，即使该行在事务启动后被更新过，同样可以继续更新。这种情况在 TiDB 使用乐观事务时会导致事务回滚，导致事务最终失败，而 TiDB 默认的悲观事务和 MySQL 是可以更新成功的。 ## 读已提交隔离级别 (Read Committed) From 189b23cc6d6847e7c7935ea2a009a6bb8c20cfb0 Mon Sep 17 00:00:00 2001 From: you06 Date: Fri, 13 Aug 2021 12:07:46 +0800 Subject: [PATCH 2/3] update Signed-off-by: you06 --- optimistic-transaction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 9dba3f7b2330..15724814dce3 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -64,7 +64,7 @@ summary: 了解 TiDB 的乐观事务模型。 ## 事务的重试 -使用乐观事务模型时，在高冲突率的场景中，事务容易发生写写冲突而导致提交失败。MySQL 使用悲观事务模型，在执行写入类型的 SQL 语句的过程中进行加锁并且在 Repeatable Read 隔离级下增加了当前读的机制，所以提交时一般不会出现异常。为了降低应用改造难度，TiDB 提供了数据库内部自动重试机制。 +使用乐观事务模型时，在高冲突率的场景中，事务容易发生写写冲突而导致提交失败。MySQL 使用悲观事务模型，在执行写入类型的 SQL 语句的过程中进行加锁并且在 Repeatable Read 隔离级下使用了当前读的机制，能够读取到最新的数据，所以提交时一般不会出现异常。为了降低应用改造难度，TiDB 提供了数据库内部自动重试机制。 ### 重试机制 From 7e821dfa5655a344ce56578b2a77211fa2e3703c Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Mon, 30 Aug 2021 19:09:09 +0800 Subject: [PATCH 3/3] a tiny fix --- optimistic-transaction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 15724814dce3..f0ac45051b14 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -64,7 +64,7 @@ summary: 了解 TiDB 的乐观事务模型。 ## 事务的重试 -使用乐观事务模型时，在高冲突率的场景中，事务容易发生写写冲突而导致提交失败。MySQL 使用悲观事务模型，在执行写入类型的 SQL 语句的过程中进行加锁并且在 Repeatable Read 隔离级下使用了当前读的机制，能够读取到最新的数据，所以提交时一般不会出现异常。为了降低应用改造难度，TiDB 提供了数据库内部自动重试机制。 +使用乐观事务模型时，在高冲突率的场景中，事务容易发生写写冲突而导致提交失败。MySQL 使用悲观事务模型，在执行写入类型的 SQL 语句的过程中进行加锁并且在 Repeatable Read 隔离级别下使用了当前读的机制，能够读取到最新的数据，所以提交时一般不会出现异常。为了降低应用改造难度，TiDB 提供了数据库内部自动重试机制。 ### 重试机制