faq/tidb.md: update wording about transaction size limit

faq/tidb.md

@@ -85,39 +85,35 @@ TiDB 字符集默认就是 UTF8 而且目前只支持 UTF8，字符串就是 mem
 
 在 TiDB 中用户名最长为 32 字符。
 
-#### 1.1.18 一个事务中的语句数量最大是多少？
-
-一个事务中的语句数量，默认限制最大为 5000 条。
-
-#### 1.1.19 TiDB 是否支持 XA？
+#### 1.1.18 TiDB 是否支持 XA？
 
 虽然 TiDB 的 JDBC 驱动用的就是 MySQL JDBC（Connector / J），但是当使用 Atomikos 的时候，数据源要配置成类似这样的配置：`type="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource"`。MySQL JDBC XADataSource 连接 TiDB 的模式目前是不支持的。MySQL JDBC 中配置好的 XADataSource 模式，只对 MySQL 数据库起作用（DML 去修改 redo 等）。
 
 Atomikos 配好两个数据源后，JDBC 驱动都要设置成 XA 模式，然后 Atomikos 在操作 TM 和 RM（DB）的时候，会通过数据源的配置，发起带有 XA 指令到 JDBC 层，JDBC 层 XA 模式启用的情况下，会对 InnoDB（如果是 MySQL 的话）下发操作一连串 XA 逻辑的动作，包括 DML 去变更 redo log 等，就是两阶段递交的那些操作。TiDB 目前的引擎版本中，没有对上层应用层 JTA / XA 的支持，不解析这些 Atomikos 发过来的 XA 类型的操作。
 
 MySQL 是单机数据库，只能通过 XA 来满足跨数据库事务，而 TiDB 本身就通过 Google 的 Percolator 事务模型支持分布式事务，性能稳定性比 XA 要高出很多，所以不会也不需要支持 XA。
 
-#### 1.1.20 show processlist 是否显示系统进程号？
+#### 1.1.19 show processlist 是否显示系统进程号？
 
 TiDB 的 `show processlist` 与 MySQL 的 `show processlist` 显示内容基本一样，不会显示系统进程号，而 ID 表示当前的 session ID。其中 TiDB 的 `show processlist` 和 MySQL 的 `show processlist` 区别如下：
 
 1）由于 TiDB 是分布式数据库，tidb-server 实例是无状态的 SQL 解析和执行引擎（详情可参考 [TiDB 整体架构](/overview.md#tidb-整体架构)），用户使用 MySQL 客户端登录的是哪个 tidb-server，`show processlist` 就会显示当前连接的这个 tidb-server 中执行的 session 列表，不是整个集群中运行的全部 session 列表；而 MySQL 是单机数据库，`show processlist` 列出的是当前整个 MySQL 数据库的全部执行 SQL 列表。
 
 2）TiDB 的 `show processlist` 显示内容比起 MySQL 来讲，多了一个当前 session 使用内存的估算值（单位 Byte）。
 
-#### 1.1.21 如何修改用户名密码和权限？
+#### 1.1.20 如何修改用户名密码和权限？
 
 TiDB 作为分布式数据库，在 TiDB 中修改用户密码建议使用 `set password for 'root'@'%' = '0101001';` 或 `alter` 方法，不推荐使用 `update mysql.user` 的方法进行，这种方法可能会造成其它节点刷新不及时的情况。修改权限也一样，都建议采用官方的标准语法。详情可参考 [TiDB 用户账户管理](/reference/security/user-account-management.md)。
 
-#### 1.1.22 TiDB 中，为什么出现后插入数据的自增 ID 反而小？
+#### 1.1.21 TiDB 中，为什么出现后插入数据的自增 ID 反而小？
 
 TiDB 的自增 ID (`AUTO_INCREMENT`) 只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。当多个线程并发往不同的 tidb-server 插入数据的时候，有可能会出现后插入的数据自增 ID 小的情况。此外，TiDB允许给整型类型的字段指定 AUTO_INCREMENT，且一个表只允许一个属性为 `AUTO_INCREMENT` 的字段。详情可参考[CREATE TABLE 语法](/reference/mysql-compatibility.md#自增-id)。
 
-#### 1.1.23 sql_mode 默认除了通过命令 set 修改，配置文件怎么修改？
+#### 1.1.22 sql_mode 默认除了通过命令 set 修改，配置文件怎么修改？
 
 TiDB 的 sql_mode 与 MySQL 的 sql_mode 设置方法有一些差别，TiDB 不支持配置文件配置设置数据库的 sql\_mode，而只能使用 set 命令去设置，具体方法为：`set @@global.sql_mode = 'STRICT_TRANS_TABLES';`。
 
-#### 1.1.24 TiDB 支持哪些认证协议，过程是怎样的？
+#### 1.1.23 TiDB 支持哪些认证协议，过程是怎样的？
 
 这一层跟 MySQL 一样，走的 SASL 认证协议，用于用户登录认证，对密码的处理流程。
 
@@ -842,11 +838,9 @@ TiDB 读流量可以通过增加 TiDB server 进行扩展，总读容量无限
 
 #### 4.3.3 Transaction too large 是什么原因，怎么解决？
 
-由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制：
+TiDB 限制了单条 KV entry 不超过 6MB。
 
-- 单个事务包含的 SQL 语句不超过 5000 条（默认）
-- 单条 KV entry 不超过 6MB
-- KV entry 的总大小不超过 100MB
+分布式事务要做两阶段提交，而且底层还需要做 Raft 复制。如果一个事务非常大，提交过程会非常慢，事务写冲突概率会增加，而且事务失败后回滚会导致不必要的性能开销。所以我们设置了 key-value entry 的总大小默认不超过 100MB。如果业务需要使用大事务，可以修改配置文件中的 `txn-total-size-limit` 配置项进行调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。
 
 在 Google 的 Cloud Spanner 上面，也有类似的[限制](https://cloud.google.com/spanner/docs/limits)。
 

reference/transactions/overview.md

@@ -198,17 +198,14 @@ COMMIT;
 
 ### 大事务
 
+由于底层存储引擎的限制，TiDB 要求单个键值对不超过 6 MB。
+
 由于 TiDB 两阶段提交的要求，修改数据的单个事务过大时会存在以下问题：
 
 * 客户端在提交之前，数据都写在内存中，而数据量过多时易导致 OOM (Out of Memory) 错误。
 * 在第一阶段写入数据耗时增加，与其他事务出现写冲突的概率会指数级增长。
 * 最终导致事务完成提交的耗时增加。
 
-因此，TiDB 对事务做了一些限制：
-
-* 单个事务包含的 SQL 语句不超过 5000 条（默认）
-* 每个键值对不超过 6 MB
-
 为了使性能达到最优，建议每 100～500 行写入一个事务。
 
-TiDB 设置了键值对的总大小不超过 100 MB 默认限制，可以通过配置文件中的配置项 `txn-total-size-limit` 进行修改，最大支持到 10GB。实际的单个事务大小限制还取决于用户的内存，执行大事务时 TiDB 进程的内存消耗大约是事务大小 6 倍以上。
+TiDB 设置了单个事务的键值对的总大小不超过 100 MB，这个默认值可以通过配置文件中的配置项 `txn-total-size-limit` 进行修改，最大支持到 10GB。实际的单个事务大小限制还取决于用户的内存，执行大事务时 TiDB 进程的内存消耗大约是事务大小 6 倍以上。