dev/reference/best-practices: update optimistic transaction document

dev/reference/best-practices/optimistic-transaction.md

@@ -103,26 +103,28 @@ COMMIT;
 通过分析两阶段提交的过程，可以发现单个事务过大时会存在以下问题：
 
 * 客户端在提交之前，数据都写在内存中，而数据量过多时易导致 OOM (Out of Memory) 错误。
-* 在第一阶段写入数据时，与其他事务出现冲突的概率会指数级增长，使事务之间相互阻塞影响。
+* 在第一阶段写入数据耗时增加，与其他事务出现写冲突的概率会指数级增长。
 * 最终导致事务完成提交的耗时增加。
 
-因此，TiDB 特意对事务的大小做了一些限制：
+TiDB 对事务做了一些限制：
 
 * 单个事务包含的 SQL 语句不超过 5000 条（默认）
 * 每个键值对不超过 6 MB
-* 键值对的总数不超过 300000
-* 键值对的总大小不超过 100 MB
 
 为了使性能达到最优，建议每 100～500 行写入一个事务。
 
+TiDB 设置了键值对的总大小不超过 100 MB 默认限制，可以通过配置文件中的配置项 `txn-total-size-limit` 进行修改，最大支持到 10GB。实际的单个事务大小限制还取决于用户的内存，执行大事务时 TiDB 进程的内存消耗大约是事务大小 6 倍以上。
+
 ## 事务冲突
 
 事务的冲突，主要指事务并发执行时对相同的 Key 进行了读写操作。冲突主要有两种形式：
 
 * 读写冲突：部分事务进行读操作时，有事务在同一时间对相同的 Key 进行写操作。
 * 写写冲突：不同事务同时对相同的 Key 进行写操作。
 
-在 TiDB 的乐观锁机制中，只有在客户端执行 `commit` 时，才会触发两阶段提交并检测是否存在写写冲突。也就是说，在乐观事务下，如果存在写写冲突，在事务提交阶段就会暴露出来，因而更容易被用户感知。
+在 TiDB 当前的事务模型下，不会出现读写冲突，所有的读操作都不会被写操作阻塞。
+
+对于写写冲突，在 TiDB 的乐观锁机制中，只有在客户端执行 `commit` 时，才会触发两阶段提交并检测是否存在写写冲突。也就是说，在乐观事务下，如果存在写写冲突，只有到事务提交阶段才会暴露出来。相对而言，悲观事务则在执行过程中就会暴露。
 
 ### 默认冲突行为