From 3d748fcf9be484442fcb66045acffed80687afb6 Mon Sep 17 00:00:00 2001 From: wjhuang2016 Date: Mon, 24 Nov 2025 19:12:06 +0800 Subject: [PATCH 1/5] init Signed-off-by: wjhuang2016 --- sql-statements/sql-statement-modify-column.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index 61f81adc309e..4c5a796da3a2 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -14,6 +14,12 @@ aliases: ['/docs-cn/dev/sql-statements/sql-statement-modify-column/','/docs-cn/d - `DECIMAL` 精度修改 - 从 `VARCHAR(10)` 到 `VARCHAR(5)` 的长度压缩 +从 v8.5.4 版本起，TiDB 优化了部分 Reorg-Data 类型变更的执行效率。在 [SQL 模式](/sql-mode.md)非严格模式（即 `sql_mode` 值包含 `STRICT_TRANS_TABLES` 或 `STRICT_ALL_TABLES`），以下类型变更将不再进行数据重建（Meta-Only 变更）： +- 整数类型之间的变更（例如 `BIGINT` 到 `INT`） +- 字符串类型之间的变更（例如 `VARCHAR(200)` 到 `VARCHAR(100)`） + +注意：VARCHAR 类型往 CHAR 类型变更时，要求所有的旧数据的尾部均不包含空格，否则需要进行 Reorg-Data。 + ## 语法图 ```ebnf+diagram @@ -168,7 +174,7 @@ CREATE TABLE `t1` ( > ERROR 1406 (22001): Data Too Long, field len 4, data len 5 > ``` > -> - 由于和 Async Commit 功能兼容，DDL 在开始进入到 Reorg Data 前会有一定时间（约 2.5s）的等待处理： +> - 由于和 Async Commit 功能兼容, 在关闭元数据锁的情况下，DDL 在开始进入到 Reorg Data 前会有一定时间（约 2.5s）的等待处理： > > ``` > Query OK, 0 rows affected (2.52 sec) From 72913a654048035f04e493885ac7b265ffc41be4 Mon Sep 17 00:00:00 2001 From: wjHuang Date: Fri, 12 Dec 2025 16:19:09 +0800 Subject: [PATCH 2/5] Apply suggestions from code review Co-authored-by: Ruihao Chen Co-authored-by: Grace Cai --- sql-statements/sql-statement-modify-column.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index 4c5a796da3a2..5f8e83295720 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -14,11 +14,13 @@ aliases: ['/docs-cn/dev/sql-statements/sql-statement-modify-column/','/docs-cn/d - `DECIMAL` 精度修改 - 从 `VARCHAR(10)` 到 `VARCHAR(5)` 的长度压缩 -从 v8.5.4 版本起，TiDB 优化了部分 Reorg-Data 类型变更的执行效率。在 [SQL 模式](/sql-mode.md)非严格模式（即 `sql_mode` 值包含 `STRICT_TRANS_TABLES` 或 `STRICT_ALL_TABLES`），以下类型变更将不再进行数据重建（Meta-Only 变更）： +从 v8.5.4 版本起，TiDB 优化了部分 Reorg-Data 类型变更的执行效率。在 [SQL 模式](/sql-mode.md)严格模式（即 `sql_mode` 值包含 `STRICT_TRANS_TABLES` 或 `STRICT_ALL_TABLES`），以下类型变更将不再进行表数据重建，只进行部分索引的重建： - 整数类型之间的变更（例如 `BIGINT` 到 `INT`） - 字符串类型之间的变更（例如 `VARCHAR(200)` 到 `VARCHAR(100)`） -注意：VARCHAR 类型往 CHAR 类型变更时，要求所有的旧数据的尾部均不包含空格，否则需要进行 Reorg-Data。 +> **注意：** +> +> 当 `VARCHAR` 转换为 `CHAR` 时，要求所有原数据的末尾均不包含空格；若不满足该条件，TiDB 仍会执行 Reorg-Data。 ## 语法图 From 211dbf578800b2b2450c03dd0ab24345a7a41e68 Mon Sep 17 00:00:00 2001 From: wjHuang Date: Fri, 12 Dec 2025 16:19:32 +0800 Subject: [PATCH 3/5] Update sql-statement-modify-column.md --- sql-statements/sql-statement-modify-column.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index 5f8e83295720..31c15b59ba98 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -14,7 +14,7 @@ aliases: ['/docs-cn/dev/sql-statements/sql-statement-modify-column/','/docs-cn/d - `DECIMAL` 精度修改 - 从 `VARCHAR(10)` 到 `VARCHAR(5)` 的长度压缩 -从 v8.5.4 版本起，TiDB 优化了部分 Reorg-Data 类型变更的执行效率。在 [SQL 模式](/sql-mode.md)严格模式（即 `sql_mode` 值包含 `STRICT_TRANS_TABLES` 或 `STRICT_ALL_TABLES`），以下类型变更将不再进行表数据重建，只进行部分索引的重建： +从 v8.5.5 版本起，TiDB 优化了部分 Reorg-Data 类型变更的执行效率。在 [SQL 模式](/sql-mode.md)严格模式（即 `sql_mode` 值包含 `STRICT_TRANS_TABLES` 或 `STRICT_ALL_TABLES`），以下类型变更将不再进行表数据重建，只进行部分索引的重建： - 整数类型之间的变更（例如 `BIGINT` 到 `INT`） - 字符串类型之间的变更（例如 `VARCHAR(200)` 到 `VARCHAR(100)`） From 7c42b7ed7349f223996c182907c758160a18cca1 Mon Sep 17 00:00:00 2001 From: wjHuang Date: Fri, 12 Dec 2025 16:23:44 +0800 Subject: [PATCH 4/5] Update sql-statement-modify-column.md --- sql-statements/sql-statement-modify-column.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index 31c15b59ba98..afb3c6ac2e23 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -15,6 +15,7 @@ aliases: ['/docs-cn/dev/sql-statements/sql-statement-modify-column/','/docs-cn/d - 从 `VARCHAR(10)` 到 `VARCHAR(5)` 的长度压缩 从 v8.5.5 版本起，TiDB 优化了部分 Reorg-Data 类型变更的执行效率。在 [SQL 模式](/sql-mode.md)严格模式（即 `sql_mode` 值包含 `STRICT_TRANS_TABLES` 或 `STRICT_ALL_TABLES`），以下类型变更将不再进行表数据重建，只进行部分索引的重建： + - 整数类型之间的变更（例如 `BIGINT` 到 `INT`） - 字符串类型之间的变更（例如 `VARCHAR(200)` 到 `VARCHAR(100)`） From b75386e38dcf3accc9f283d0b3b33566876272c2 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 12 Dec 2025 17:23:25 +0800 Subject: [PATCH 5/5] Apply suggestions from code review --- sql-statements/sql-statement-modify-column.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index afb3c6ac2e23..7fb6d42ae8a7 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -14,7 +14,7 @@ aliases: ['/docs-cn/dev/sql-statements/sql-statement-modify-column/','/docs-cn/d - `DECIMAL` 精度修改 - 从 `VARCHAR(10)` 到 `VARCHAR(5)` 的长度压缩 -从 v8.5.5 版本起，TiDB 优化了部分 Reorg-Data 类型变更的执行效率。在 [SQL 模式](/sql-mode.md)严格模式（即 `sql_mode` 值包含 `STRICT_TRANS_TABLES` 或 `STRICT_ALL_TABLES`），以下类型变更将不再进行表数据重建，只进行部分索引的重建： +从 v8.5.5 和 v9.0.0 版本起，TiDB 优化了部分 Reorg-Data 类型变更的执行效率。在 [SQL 模式](/sql-mode.md)严格模式（即 `sql_mode` 值包含 `STRICT_TRANS_TABLES` 或 `STRICT_ALL_TABLES`），以下类型变更将不再进行表数据重建，只进行部分索引的重建： - 整数类型之间的变更（例如 `BIGINT` 到 `INT`） - 字符串类型之间的变更（例如 `VARCHAR(200)` 到 `VARCHAR(100)`） @@ -177,7 +177,7 @@ CREATE TABLE `t1` ( > ERROR 1406 (22001): Data Too Long, field len 4, data len 5 > ``` > -> - 由于和 Async Commit 功能兼容, 在关闭元数据锁的情况下，DDL 在开始进入到 Reorg Data 前会有一定时间（约 2.5s）的等待处理： +> - 由于和 Async Commit 功能兼容，在关闭[元数据锁](/metadata-lock.md)的情况下，DDL 在开始进入到 Reorg Data 前会有一定时间（约 2.5s）的等待处理： > > ``` > Query OK, 0 rows affected (2.52 sec)