然而，仍有一些 MySQL 的特性和行为，TiDB 目前暂时不支持或表现与 MySQL 有差异。除此之外，TiDB 提供了一些扩展语法和功能，为用户提供更多的便利。

TiDB 仍处在快速发展的道路上，对 MySQL 功能和行为的支持方面，正按 的规划在前行。

先从总体上概括 TiDB 和 MySQL 兼容策略，如下表：

截至 4.0 版本，TiDB 与 MySQL 的区别总结如下表：

5.2 区别点详述及应对方案

TiDB 目前支持以下字符集：

注意：TiDB 的默认字符集为 ，MySQL 5.7 中为 latin1，MySQL 8.0 中修改为 utf8mb4。 当指定的字符集为 utf8 或 utf8mb4 时，TiDB 仅支持合法的 UTF8 字符。对于不合法的字符，会报错：incorrect utf8 value，该字符合法性检查与 MySQL 8.0 一致。对于 MySQL 5.7 及以下版本，会存在允许插入非法 UTF8 字符，但同步到 TiDB 报错的情况。此时，可以通过 TiDB 配置 “tidb_skip_utf8_check” 跳过 UTF8 字符合法性检查强制写入 TiDB。

每一个字符集，都有一个默认的 Collation，例如 utf8 的默认 Collation 为 utf8_bin，TiDB 中字符集的默认 Collation 与 MySQL 不一致，具体如下：

在 4.0 版本之前，TiDB 中可以任意指定字符集对应的所有 Collation，并把它们按照默认 Collation 处理，即以编码字节序为字符定序。同时，并未像 MySQL 一样，在比较前按照 Collation 的 PADDING 属性将字符补齐空格。因此，会造成以下的行为区别：

tidb> create table t(a varchar(20) charset utf8mb4 collate utf8mb4_general_ci primary key);
Query OK, 0 rows affected
tidb> insert into t values ('A');
tidb> insert into t values ('a');
tidb> insert into t1 values ('a ');
Query OK, 1 row affected // MySQL 中，由于补齐空格比较，报错 Duplicate entry 'a '

在新 Collation 启用后，TiDB 修正了 utf8mb4_general_bin 和 utf8_general_bin 的 PADDING 行为，会将字符串补齐空格后比较；同时支持了 utf8mb4_general_ci 和 utf8_general_ci，这两个 Collation 与 MySQL 保持兼容。

(2) 系统时区

在 MySQL 中，系统时区 system_time_zone 在 MySQL 服务启动时通过 指定。

对于 TiDB 而言，作为一个分布式数据库，TiDB 需要保证整个集群的系统时区始终一致。因此 TiDB 的系统时区在集群初始化时，由负责初始化的 TiDB 节点环境变量 TZ 决定。集群初始化后，固定在集群状态表 mysql.tidb 中：

tidb> select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='system_tz';
| VARIABLE_VALUE |
+----------------+
| Asia/Shanghai  |
+----------------+
1 row in set (0.00 sec)

请注意，这意味着 TiDB 的系统时区在初始化后不再更改。若需要改变集群的时区，可以显式指定 time_zone 系统变量，例如：

Query OK, 0 rows affected (0.00 sec)