pingcap · ti-chi-bot · Jan 12, 2022 · Dec 31, 2021 · Dec 31, 2021 · Jan 5, 2022
diff --git a/TOC.md b/TOC.md
@@ -538,7 +538,9 @@
     - [视图](/views.md)
     - [分区表](/partitioned-table.md)
     - [临时表](/temporary-tables.md)
-    - [字符集和排序规则](/character-set-and-collation.md)
+    - 字符集和排序
+      - [概述](/character-set-and-collation.md)
+      - [GBK](/character-set-gbk.md)
     - [Placement Rules in SQL](/placement-rules-in-sql.md)
     - 系统表
       - [`mysql`](/mysql-schema.md)

diff --git a/br/backup-and-restore-tool.md b/br/backup-and-restore-tool.md
@@ -66,6 +66,9 @@ SST 文件以 `storeID_regionID_regionEpoch_keyHash_cf` 的格式命名。格式
 BR 和 TiDB 集群的兼容性问题分为以下两方面：
 
 + BR 部分版本和 TiDB 集群的接口不兼容
+
+  BR 在 v5.4.0 之前不支持恢复 `charset=GBK` 的表。并且，任何版本的 BR 都不支持恢复 `charset=GBK` 的表到 5.4.0 之前的 TiDB 集群。
+
 + 某些功能在开启或关闭状态下，会导致 KV 格式发生变化，因此备份和恢复期间如果没有统一开启或关闭，就会带来不兼容的问题
 
 下表整理了会导致 KV 格式发生变化的功能。

diff --git a/character-set-and-collation.md b/character-set-and-collation.md
@@ -56,15 +56,16 @@ SHOW CHARACTER SET;
 ```
 
 ```sql
-+---------|---------------|-------------------|--------+
-| Charset | Description   | Default collation | Maxlen |
-+---------|---------------|-------------------|--------+
-| utf8    | UTF-8 Unicode | utf8_bin          |      3 |
-| utf8mb4 | UTF-8 Unicode | utf8mb4_bin       |      4 |
-| ascii   | US ASCII      | ascii_bin         |      1 |
-| latin1  | Latin1        | latin1_bin        |      1 |
-| binary  | binary        | binary            |      1 |
-+---------|---------------|-------------------|--------+
++---------+-------------------------------------+-------------------+--------+
+| Charset | Description                         | Default collation | Maxlen |
++---------+-------------------------------------+-------------------+--------+
+| ascii   | US ASCII                            | ascii_bin         |      1 |
+| binary  | binary                              | binary            |      1 |
+| gbk     | Chinese Internal Code Specification | gbk_bin           |      2 |
+| latin1  | Latin1                              | latin1_bin        |      1 |
+| utf8    | UTF-8 Unicode                       | utf8_bin          |      3 |
+| utf8mb4 | UTF-8 Unicode                       | utf8mb4_bin       |      4 |
++---------+-------------------------------------+-------------------+--------+
 5 rows in set (0.00 sec)
 ```
 
@@ -80,6 +81,7 @@ mysql> show collation;
 | binary      | binary  |   63 | Yes     | Yes      |       1 |
 | ascii_bin   | ascii   |   65 | Yes     | Yes      |       1 |
 | utf8_bin    | utf8    |   83 | Yes     | Yes      |       1 |
+| gbk_bin     | gbk     |   87 | Yes     | Yes      |       1 |
 +-------------+---------+------+---------+----------+---------+
 5 rows in set (0.01 sec)
 ```
@@ -111,6 +113,8 @@ SHOW COLLATION WHERE Charset = 'utf8mb4';
 3 rows in set (0.00 sec)
 ```
 
+TiDB 对 GBK 字符集的支持详情见 [GBK](/character-set-gbk.md)。
+
 ## TiDB 中的 `utf8` 和 `utf8mb4`
 
 MySQL 限制字符集 `utf8` 为最多 3 个字节。这足以存储在基本多语言平面 (BMP) 中的字符，但不足以存储表情符号 (emoji) 等字符。因此，建议改用字符集`utf8mb4`。
@@ -418,9 +422,9 @@ SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME='new_collation_enabled
 1 row in set (0.00 sec)
 ```
 
-在新的排序规则框架下，TiDB 能够支持 `utf8_general_ci`、`utf8mb4_general_ci`、`utf8_unicode_ci` 和 `utf8mb4_unicode_ci` 这几种排序规则，与 MySQL 兼容。
+在新的排序规则框架下，TiDB 能够支持 `utf8_general_ci`、`utf8mb4_general_ci`、`utf8_unicode_ci`、`utf8mb4_unicode_ci`、`gbk_chinese_ci` 和 `gbk_bin` 这几种排序规则，与 MySQL 兼容。
 
-使用 `utf8_general_ci`、`utf8mb4_general_ci`、`utf8_unicode_ci` 和 `utf8mb4_unicode_ci` 中任一种时，字符串之间的比较是大小写不敏感 (case-insensitive) 和口音不敏感 (accent-insensitive) 的。同时，TiDB 还修正了排序规则的 `PADDING` 行为：
+使用 `utf8_general_ci`、`utf8mb4_general_ci`、`utf8_unicode_ci` 、 `utf8mb4_unicode_ci` 和 `gbk_chinese_ci` 中任一种时，字符串之间的比较是大小写不敏感 (case-insensitive) 和口音不敏感 (accent-insensitive) 的。同时，TiDB 还修正了排序规则的 `PADDING` 行为：
 
 {{< copyable "sql" >}}
 

diff --git a/character-set-gbk.md b/character-set-gbk.md
@@ -0,0 +1,97 @@
+---
+title: GBK
+summary: 本文介绍 TiDB 对 GBK 字符集的支持情况。
+---
+
+# GBK
+
+TiDB 从 v5.4.0 开始支持 GBK 字符集。本文档介绍 TiDB 对 GBK 字符集的支持和兼容情况。
+
+```sql
+SHOW CHARACTER SET WHERE CHARSET = 'gbk';
++---------+-------------------------------------+-------------------+--------+
+| Charset | Description                         | Default collation | Maxlen |
++---------+-------------------------------------+-------------------+--------+
+| gbk     | Chinese Internal Code Specification | gbk_bin           |      2 |
++---------+-------------------------------------+-------------------+--------+
+1 row in set (0.00 sec)
+
+SHOW COLLATION WHERE CHARSET = 'gbk';
++----------------+---------+------+---------+----------+---------+
+| Collation      | Charset | Id   | Default | Compiled | Sortlen |
++----------------+---------+------+---------+----------+---------+
+| gbk_bin        | gbk     |   87 |         | Yes      |       1 |
++----------------+---------+------+---------+----------+---------+
+1 rows in set (0.00 sec)
+```
+
+## 排序规则
+
+MySQL 的字符集默认排序规则是 `gbk_chinese_ci`。与 MySQL 不同，TiDB GBK 字符集的默认排序规则为 `gbk_bin`。另外，TiDB 支持的 `gbk_bin` 与 MySQL 支持的 `gbk_bin` 排序规则也不一致，TiDB 是将 GBK 转换成 UTF8MB4 然后做二进制排序。
+
+如果要使 TiDB 兼容 MySQL 的 GBK 字符集排序规则，你需要在初次初始化 TiDB 集群时设置 TiDB 配置项[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap) 为 `true` 来开启[新的排序规则框架](/character-set-and-collation.md#新框架下的排序规则支持)。
+
+开启新的排序规则框架后，如果查看 GBK 字符集对应的排序规则，你可以看到 TiDB GBK 默认排序规则已经切换为 `gbk_chinese_ci`。
+
+```sql
+SHOW CHARACTER SET WHERE CHARSET = 'gbk';
++---------+-------------------------------------+-------------------+--------+
+| Charset | Description                         | Default collation | Maxlen |
++---------+-------------------------------------+-------------------+--------+
+| gbk     | Chinese Internal Code Specification | gbk_chinese_ci    |      2 |
++---------+-------------------------------------+-------------------+--------+
+1 row in set (0.00 sec)
+
+SHOW COLLATION WHERE CHARSET = 'gbk';
++----------------+---------+------+---------+----------+---------+
+| Collation      | Charset | Id   | Default | Compiled | Sortlen |
++----------------+---------+------+---------+----------+---------+
+| gbk_bin        | gbk     |   87 |         | Yes      |       1 |
+| gbk_chinese_ci | gbk     |   28 | Yes     | Yes      |       1 |
++----------------+---------+------+---------+----------+---------+
+2 rows in set (0.00 sec)
+```
+
+## MySQL 兼容性
+
+### 非法字符兼容性
+
+* 在系统变量 [`character_set_client`](/system-variables.md#character_set_client) 和 [`character_set_connection`](/system-variables.md#character_set_connection) 不同时设置为 `gbk` 的情况下，TiDB 处理非法字符的方式与 MySQL 一致。
+* 在 `character_set_client` 和 `character_set_connection` 同时为 `gbk` 的情况下， TiDB 处理非法字符的方式与 MySQL 有所区别。
+
+    - MySQL 处理非法 GBK 字符集时，对读和写操作的处理方式不同。
+    - TiDB 处理非法 GBK 字符集时，对读和写操作的处理方式相同。TiDB 在严格模式下读写非法 GBK 字符都会报错，在非严格模式下，读写非法 GBK 字符都会用 `?` 替换。
+
+例如，当 `SET NAMES gbk` 时，如果分别在 MySQL 和 TiDB 上通过 `CREATE TABLE gbk_table(a VARCHAR(32) CHARACTER SET gbk)` 语句建表，然后按照下表中的 SQL 语句进行操作，就能看到具体的区别。
+
+| 数据库    |    如果设置的 SQL 模式包含 `STRICT_ALL_TABLES` 或 `STRICT_TRANS_TABLES`                                               | 如果设置的 SQL 模式不包含 `STRICT_ALL_TABLES` 和  `STRICT_TRANS_TABLES`                                                                     |
+|-------|-------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------|
+| MySQL | `SELECT HEX('一a');` <br /> `e4b88061`<br /><br />`INSERT INTO gbk_table values('一a');`<br /> `Incorrect Error`       | `SELECT HEX('一a');` <br /> `e4b88061`<br /><br />`INSERT INTO gbk_table VALUES('一a');`<br />`SELECT HEX(a) FROM gbk_table;`<br /> `e4b8` |
+| TiDB  | `SELECT HEX('一a');` <br /> `Incorrect Error`<br /><br />`INSERT INTO gbk_table VALUES('一a');`<br /> `Incorrect Error` | `SELECT HEX('一a');` <br /> `e4b83f`<br /><br />`INSERT INTO gbk_table VALUES('一a');`<br />`SELECT HEX(a) FROM gbk_table;`<br /> `e4b83f`  |
+
+说明：该表中 `SELECT HEX('一a');` 在 `utf8mb4` 字节集下的结果为 `e4b88061`。
+
+### 其它
+
+* 目前 TiDB 不支持通过 `ALTER TABLE` 语句将其它字符集类型改成 `gbk` 或者从 `gbk` 转成其它字符集类型。
+
+* TiDB 不支持使用 `_gbk`， 比如：
+
+  ```sql
+  CREATE TABLE t(a CHAR(10) CHARSET BINARY);
+  Query OK, 0 rows affected (0.00 sec)
+  INSERT INTO t VALUES (_gbk'啊');
+  ERROR 1115 (42000): Unsupported character introducer: 'gbk'
+  ```
+
+* 对于 `ENUM` 和 `SET` 类型中的二进制字符，TiDB 目前都会将其作为 `utf8mb4` 字符集处理。
+
+## 组件兼容性
+
+* TiCDC 和 TiFlash 目前不支持 GBK 字符集。
+
+* TiDB Data Migration (DM) 在 v5.4.0 之前不支持将 `charset=GBK` 的表迁移到 TiDB。
+
+* TiDB Lightning 在 v5.4.0 之前不支持导入 `charset=GBK` 的表。
+
+* TiDB Backup & Restore（BR）在 v5.4.0 之前不支持恢复 `charset=GBK` 的表。另外，任何版本的 BR 都不支持恢复 `charset=GBK` 的表到 5.4.0 之前的 TiDB 集群。
diff --git a/dm/dm-overview.md b/dm/dm-overview.md
@@ -101,3 +101,7 @@ DM 支持对源数据的分库分表进行合并迁移，但有一些使用限
 + 数据源 MySQL 实例切换
 
     - 当 DM-worker 通过虚拟 IP（VIP）连接到 MySQL 且要切换 VIP 指向的 MySQL 实例时，DM 内部不同的 connection 可能会同时连接到切换前后不同的 MySQL 实例，造成 DM 拉取的 binlog 与从上游获取到的其他状态不一致，从而导致难以预期的异常行为甚至数据损坏。如需切换 VIP 指向的 MySQL 实例，请参考[虚拟 IP 环境下的上游主从切换](/dm/usage-scenario-master-slave-switch.md#虚拟-ip-环境下切换-dm-worker-与-mysql-实例的连接)对 DM 手动执行变更。
+
++ GBK 字符集兼容性限制
+
+    - DM 在 v5.4.0 之前不支持将 `charset=GBK` 的表迁移到 TiDB。
diff --git a/mysql-compatibility.md b/mysql-compatibility.md
@@ -29,7 +29,7 @@ aliases: ['/docs-cn/dev/mysql-compatibility/','/docs-cn/dev/reference/mysql-comp
 * 自定义函数
 * 外键约束 [#18209](https://github.com/pingcap/tidb/issues/18209)
 * 全文/空间函数与索引 [#1793](https://github.com/pingcap/tidb/issues/1793)
-* 非 `ascii`/`latin1`/`binary`/`utf8`/`utf8mb4` 的字符集
+* 非 `ascii`、`latin1`、`binary`、`utf8`、`utf8mb4`、`gbk` 的字符集
 * SYS schema
 * MySQL 追踪优化器
 * XML 函数

diff --git a/tidb-lightning/tidb-lightning-overview.md b/tidb-lightning/tidb-lightning-overview.md
@@ -51,6 +51,10 @@ TiDB Lightning 还支持使用 TiDB-backend 作为后端导入数据：`tidb-lig
 
 ## 使用限制
 
-TiDB Lightning 与 TiFlash 一起使用时需要注意：
+* TiDB Lightning 与 TiFlash 一起使用时需要注意：
 
-无论是否已为一张表创建 TiFlash 副本，你均可以使用 TiDB Lightning 导入数据至该表。但该场景下 TiDB Lightning 导入数据耗费的时间更长，具体取决于 TiDB Lightning 部署机器的网卡带宽、TiFlash 节点的 CPU 及磁盘负载、TiFlash 副本数等因素。
+    无论是否已为一张表创建 TiFlash 副本，你都可以使用 TiDB Lightning 导入数据至该表。但该场景下，TiDB Lightning 导入数据耗费的时间更长，具体取决于 TiDB Lightning 部署机器的网卡带宽、TiFlash 节点的 CPU 及磁盘负载及 TiFlash 副本数等因素。
+
+* TiDB Lightning 与 TiDB 一起使用时需要注意：
+
+    TiDB Lightning 在 v5.4.0 之前不支持导入 `charset=GBK` 的表。