diff --git a/faq/tidb.md b/faq/tidb.md index 890c4c397c6c..9c1281a9d179 100755 --- a/faq/tidb.md +++ b/faq/tidb.md @@ -85,11 +85,7 @@ 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 等）。 @@ -97,7 +93,7 @@ Atomikos 配好两个数据源后，JDBC 驱动都要设置成 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` 区别如下： @@ -105,19 +101,19 @@ TiDB 的 `show processlist` 与 MySQL 的 `show processlist` 显示内容基本 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)。 diff --git a/reference/transactions/overview.md b/reference/transactions/overview.md index 22a06a39aa0f..2c88227ca50e 100644 --- a/reference/transactions/overview.md +++ b/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 倍以上。 \ No newline at end of file +TiDB 设置了单个事务的键值对的总大小不超过 100 MB，这个默认值可以通过配置文件中的配置项 `txn-total-size-limit` 进行修改，最大支持到 10GB。实际的单个事务大小限制还取决于用户的内存，执行大事务时 TiDB 进程的内存消耗大约是事务大小 6 倍以上。