From ad0a0b9528da83df73addbf2a7ca16003266bd17 Mon Sep 17 00:00:00 2001 From: tiancaiamao Date: Wed, 26 Feb 2020 20:28:06 +0800 Subject: [PATCH 1/7] faq/tidb.md: update wording about transaction size limit --- faq/tidb.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/faq/tidb.md b/faq/tidb.md index 890c4c397c6c..6c62a49639e3 100755 --- a/faq/tidb.md +++ b/faq/tidb.md @@ -842,14 +842,15 @@ TiDB 读流量可以通过增加 TiDB server 进行扩展，总读容量无限 #### 4.3.3 Transaction too large 是什么原因，怎么解决？ -由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制： +由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，提交过程非常慢，事务写冲突概率会增加，并且事务失败回滚会导致不必要的性能开销。我们对事务的做了限制： - 单个事务包含的 SQL 语句不超过 5000 条（默认） - 单条 KV entry 不超过 6MB -- KV entry 的总大小不超过 100MB 在 Google 的 Cloud Spanner 上面，也有类似的[限制](https://cloud.google.com/spanner/docs/limits)。 +默认还设置了 KV entry 的总大小不超过 100MB，如果业务需要使用大事务，可能修改配置文件中的配置项 txn-total-size-limit 调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。 + #### 4.3.4 如何批量导入？ 导入数据的时候，可以分批插入，每批最好不要超过 1w 行。 From 924bf4e7680ecf4b1ac4066052fae2f14a2041d5 Mon Sep 17 00:00:00 2001 From: tiancaiamao Date: Wed, 26 Feb 2020 21:23:04 +0800 Subject: [PATCH 2/7] Update faq/tidb.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- faq/tidb.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/faq/tidb.md b/faq/tidb.md index 6c62a49639e3..14c2da2ff740 100755 --- a/faq/tidb.md +++ b/faq/tidb.md @@ -842,7 +842,7 @@ TiDB 读流量可以通过增加 TiDB server 进行扩展，总读容量无限 #### 4.3.3 Transaction too large 是什么原因，怎么解决？ -由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，提交过程非常慢，事务写冲突概率会增加，并且事务失败回滚会导致不必要的性能开销。我们对事务的做了限制： +分布式事务要做两阶段提交，而且底层还需要做 Raft 复制。如果一个事务非常大，提交过程会非常慢，事务写冲突概率会增加，而且事务失败后回滚会导致不必要的性能开销。因此我们对事务的做了以下限制： - 单个事务包含的 SQL 语句不超过 5000 条（默认） - 单条 KV entry 不超过 6MB From 1ca8f9699bf323a60280e226b6f6a9d03b50f825 Mon Sep 17 00:00:00 2001 From: tiancaiamao Date: Wed, 26 Feb 2020 21:23:12 +0800 Subject: [PATCH 3/7] Update faq/tidb.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- faq/tidb.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/faq/tidb.md b/faq/tidb.md index 14c2da2ff740..7dc650769767 100755 --- a/faq/tidb.md +++ b/faq/tidb.md @@ -849,7 +849,7 @@ TiDB 读流量可以通过增加 TiDB server 进行扩展，总读容量无限 在 Google 的 Cloud Spanner 上面，也有类似的[限制](https://cloud.google.com/spanner/docs/limits)。 -默认还设置了 KV entry 的总大小不超过 100MB，如果业务需要使用大事务，可能修改配置文件中的配置项 txn-total-size-limit 调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。 +还默认限制 KV entry 的总大小不超过 100MB。如果业务需要使用大事务，可以修改配置文件中的 `txn-total-size-limit` 配置项进行调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。 #### 4.3.4 如何批量导入？ From 7a2f94ad382b6e15e788289312b66c7012e15f51 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Wed, 26 Feb 2020 21:38:07 +0800 Subject: [PATCH 4/7] fix a typo --- faq/tidb.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/faq/tidb.md b/faq/tidb.md index 7dc650769767..5a93f1dad32a 100755 --- a/faq/tidb.md +++ b/faq/tidb.md @@ -849,7 +849,7 @@ TiDB 读流量可以通过增加 TiDB server 进行扩展，总读容量无限 在 Google 的 Cloud Spanner 上面，也有类似的[限制](https://cloud.google.com/spanner/docs/limits)。 -还默认限制 KV entry 的总大小不超过 100MB。如果业务需要使用大事务，可以修改配置文件中的 `txn-total-size-limit` 配置项进行调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。 +我们还限制 KV entry 的总大小默认不超过 100MB。如果业务需要使用大事务，可以修改配置文件中的 `txn-total-size-limit` 配置项进行调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。 #### 4.3.4 如何批量导入？ From c793942d232d4b26fde6c4c37018ee736e450168 Mon Sep 17 00:00:00 2001 From: tiancaiamao Date: Thu, 27 Feb 2020 15:43:19 +0800 Subject: [PATCH 5/7] address comment --- faq/tidb.md | 7 ++----- reference/transactions/overview.md | 9 +++------ 2 files changed, 5 insertions(+), 11 deletions(-) diff --git a/faq/tidb.md b/faq/tidb.md index 5a93f1dad32a..575fcb1b131a 100755 --- a/faq/tidb.md +++ b/faq/tidb.md @@ -842,15 +842,12 @@ TiDB 读流量可以通过增加 TiDB server 进行扩展，总读容量无限 #### 4.3.3 Transaction too large 是什么原因，怎么解决？ -分布式事务要做两阶段提交，而且底层还需要做 Raft 复制。如果一个事务非常大，提交过程会非常慢，事务写冲突概率会增加，而且事务失败后回滚会导致不必要的性能开销。因此我们对事务的做了以下限制： +TiDB 限制了单条 KV entry 不超过 6MB。 -- 单个事务包含的 SQL 语句不超过 5000 条（默认） -- 单条 KV entry 不超过 6MB +分布式事务要做两阶段提交，而且底层还需要做 Raft 复制。如果一个事务非常大，提交过程会非常慢，事务写冲突概率会增加，而且事务失败后回滚会导致不必要的性能开销。所以我们设置了 KV entry 的总大小默认值不超过 100MB。如果业务需要使用大事务，可以修改配置文件中的 `txn-total-size-limit` 配置项进行调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。 在 Google 的 Cloud Spanner 上面，也有类似的[限制](https://cloud.google.com/spanner/docs/limits)。 -我们还限制 KV entry 的总大小默认不超过 100MB。如果业务需要使用大事务，可以修改配置文件中的 `txn-total-size-limit` 配置项进行调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。 - #### 4.3.4 如何批量导入？ 导入数据的时候，可以分批插入，每批最好不要超过 1w 行。 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 倍以上。 From 2050f046c53585da4db8dc741bdc9eeca1240f43 Mon Sep 17 00:00:00 2001 From: tiancaiamao Date: Thu, 27 Feb 2020 16:30:44 +0800 Subject: [PATCH 6/7] addrss comment --- faq/tidb.md | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/faq/tidb.md b/faq/tidb.md index 575fcb1b131a..69ef7ce15320 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 认证协议，用于用户登录认证，对密码的处理流程。 From cbe694db92cb95d51f886641d8c002c6979aa1d5 Mon Sep 17 00:00:00 2001 From: tiancaiamao Date: Fri, 28 Feb 2020 21:53:13 +0800 Subject: [PATCH 7/7] Update faq/tidb.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- faq/tidb.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/faq/tidb.md b/faq/tidb.md index 69ef7ce15320..9c1281a9d179 100755 --- a/faq/tidb.md +++ b/faq/tidb.md @@ -840,7 +840,7 @@ TiDB 读流量可以通过增加 TiDB server 进行扩展，总读容量无限 TiDB 限制了单条 KV entry 不超过 6MB。 -分布式事务要做两阶段提交，而且底层还需要做 Raft 复制。如果一个事务非常大，提交过程会非常慢，事务写冲突概率会增加，而且事务失败后回滚会导致不必要的性能开销。所以我们设置了 KV entry 的总大小默认值不超过 100MB。如果业务需要使用大事务，可以修改配置文件中的 `txn-total-size-limit` 配置项进行调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。 +分布式事务要做两阶段提交，而且底层还需要做 Raft 复制。如果一个事务非常大，提交过程会非常慢，事务写冲突概率会增加，而且事务失败后回滚会导致不必要的性能开销。所以我们设置了 key-value entry 的总大小默认不超过 100MB。如果业务需要使用大事务，可以修改配置文件中的 `txn-total-size-limit` 配置项进行调整，最大可以修改到 10G。实际的大小限制还受机器的物理内存影响。 在 Google 的 Cloud Spanner 上面，也有类似的[限制](https://cloud.google.com/spanner/docs/limits)。