From b4656d12641d3ec8a97a15af72c0e01862b4e5a8 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 19 Oct 2026 17:13:44 +0900 Subject: [PATCH 1/4] docs: fix wording that causes mistranslation in the Japanese docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - system-variables.md: describe tidb_enable_resource_control with the usual "controls whether to enable" instead of "is a switch for", which was translated literally as スイッチ. - tidb-cloud/csv-config-for-import-data.md: drop the dangling "as follows" (what follows is the source data example, not a setting) and the "then ... But" construction. - develop/java-app-best-practices.md and dev-guide-connection-parameters.md: join the sentence that was split across a code block ("If you change the three statements into the following ones: [code] Then they meet the rewrite requirement."). Co-Authored-By: Claude Opus 5.5 --- develop/dev-guide-connection-parameters.md | 4 ++-- develop/java-app-best-practices.md | 4 ++-- system-variables.md | 2 +- tidb-cloud/csv-config-for-import-data.md | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 21b1962664fdf..afe34d7f12784 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -272,7 +272,7 @@ INSERT INTO `t` (`a`) VALUES (11) ON DUPLICATE KEY UPDATE `a` = 11; INSERT INTO `t` (`a`) VALUES (12) ON DUPLICATE KEY UPDATE `a` = 12; ``` -The above `INSERT` statements cannot be rewritten into one statement. But if you change the three statements into the following ones: +The above `INSERT` statements cannot be rewritten into one statement. But if you change the three statements as follows, they meet the rewrite requirement: ```sql INSERT INTO `t` (`a`) VALUES (10) ON DUPLICATE KEY UPDATE `a` = VALUES(`a`); @@ -280,7 +280,7 @@ INSERT INTO `t` (`a`) VALUES (11) ON DUPLICATE KEY UPDATE `a` = VALUES(`a`); INSERT INTO `t` (`a`) VALUES (12) ON DUPLICATE KEY UPDATE `a` = VALUES(`a`); ``` -Then they meet the rewrite requirement. The above `INSERT` statements will be rewritten into the following one statement: +The above `INSERT` statements will be rewritten into the following one statement: ```sql INSERT INTO `t` (`a`) VALUES (10), (11), (12) ON DUPLICATE KEY UPDATE a = VALUES(`a`); diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index 6b5659afed1f6..bd8bffd96a6c4 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -166,7 +166,7 @@ insert into t (a) values (11) on duplicate key update a = 11; insert into t (a) values (12) on duplicate key update a = 12; ``` -The above `INSERT` statements cannot be rewritten into one statement. But if you change the three statements into the following ones: +The above `INSERT` statements cannot be rewritten into one statement. But if you change the three statements as follows, they meet the rewrite requirement: ```sql insert into t (a) values (10) on duplicate key update a = values(a); @@ -174,7 +174,7 @@ insert into t (a) values (11) on duplicate key update a = values(a); insert into t (a) values (12) on duplicate key update a = values(a); ``` -Then they meet the rewrite requirement. The above `INSERT` statements will be rewritten into the following one statement: +The above `INSERT` statements will be rewritten into the following one statement: ```sql insert into t (a) values (10), (11), (12) on duplicate key update a = values(a); diff --git a/system-variables.md b/system-variables.md index 6afa3f2ef831d..ee2cba01548b5 100644 --- a/system-variables.md +++ b/system-variables.md @@ -2799,7 +2799,7 @@ Assume that you have a cluster with 4 TiDB nodes and multiple TiKV nodes. In thi - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No - Default value: `ON` - Type: Boolean -- This variable is a switch for [the resource control feature](/tidb-resource-control-ru-groups.md). When this variable is set to `ON`, the TiDB cluster can isolate application resources based on resource groups. +- This variable controls whether to enable [the resource control feature](/tidb-resource-control-ru-groups.md). When this variable is set to `ON`, the TiDB cluster can isolate application resources based on resource groups. ### tidb_enable_reuse_chunk New in v6.4.0 diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index a67ec6c53f013..58e1f0fd356be 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -67,7 +67,7 @@ The following is the CSV Configuration window when you use the Import Data servi `{"key1": "val1", "key2": "val2"}` - If the content of the CSV source file is saved as JSON in the following way, then consider setting `Backslash escape = True` as follows. But this is not the standard format for CSV. + If the content of the CSV source file is saved as JSON in the following way, consider setting `Backslash escape = True`. Note that this is not the standard format for CSV. `"{\"key1\": \"val1\", \"key2\":\"val2\" }"` From 1ae254635cb8741f09961f0d93a54889fbad38fc Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 20 Oct 2026 13:50:39 +0900 Subject: [PATCH 2/4] system-variables: fix "connection orders" in tidb_opt_join_reorder_threshold Co-Authored-By: Claude Opus 5.5 --- system-variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-variables.md b/system-variables.md index ee2cba01548b5..c1e917b24c48c 100644 --- a/system-variables.md +++ b/system-variables.md @@ -4696,7 +4696,7 @@ mysql> desc select count(distinct a) from test.t; - Default value: `0` - Range: `[0, 2147483647]` - This variable is used to control the selection of the TiDB Join Reorder algorithm. When the number of nodes participating in Join Reorder is greater than this threshold, TiDB selects the greedy algorithm, and when it is less than this threshold, TiDB selects the dynamic programming algorithm. -- Currently, for OLTP queries, it is recommended to keep the default value. For OLAP queries, it is recommended to set the variable value to 10~15 to get better connection orders in OLAP scenarios. +- Currently, for OLTP queries, it is recommended to keep the default value. For OLAP queries, it is recommended to set the variable value to 10~15 to get better join orders in OLAP scenarios. ### tidb_opt_join_reorder_through_sel New in v8.5.6 and v9.0.0 From 35ee7eef0ac8ec3aeca05ef9a568930404c481be Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 20 Oct 2026 14:09:49 +0900 Subject: [PATCH 3/4] tidb-scheduling: clarify two sentences about leaders and Region balancing Co-Authored-By: Claude Opus 5.5 --- tidb-scheduling.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tidb-scheduling.md b/tidb-scheduling.md index 89a7300cc349e..33e6d78f88e66 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -23,9 +23,9 @@ Now consider about the following situations: * Replicas of all Regions. * If the number of replicas is not enough for some Regions, PD needs to complete them. * If the number of replicas is more than expected (for example, the failed store re-joins into the cluster after recovery), PD needs to delete them. -* Read/Write operations are performed on leaders, which cannot be distributed only on a few individual stores; +* Read/Write operations are performed on leaders, so leaders cannot be concentrated on only a few individual stores; * Not all Regions are hot, so loads of all TiKV stores need to be balanced; -* When Regions are in balancing, data transferring utilizes much network/disk traffic and CPU time, which can influence online services. +* When Regions are being balanced, data transferring utilizes much network/disk traffic and CPU time, which can influence online services. These situations can occur at the same time, which makes it harder to resolve. Also, the whole system is changing dynamically, so a scheduler is needed to collect all information about the cluster, and then adjust the cluster. So, PD is introduced into the TiDB cluster. From ac598ef299a10cb34870ea68688b80d6eb9cf10b Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 20 Oct 2026 14:13:33 +0900 Subject: [PATCH 4/4] tidb-cloud: describe the JSON field, not the whole CSV file, in the Backslash escape example Co-Authored-By: Claude Opus 5.5 --- tidb-cloud/csv-config-for-import-data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index 58e1f0fd356be..12cac07fda041 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -67,7 +67,7 @@ The following is the CSV Configuration window when you use the Import Data servi `{"key1": "val1", "key2": "val2"}` - If the content of the CSV source file is saved as JSON in the following way, consider setting `Backslash escape = True`. Note that this is not the standard format for CSV. + If a JSON field in the CSV source file is stored in the following way, consider setting `Backslash escape = True`. Note that this is not the standard format for CSV. `"{\"key1\": \"val1\", \"key2\":\"val2\" }"`