tidb mysql兼容_兼容性 - 与 MySQL 的兼容性 - 《TiDB v4.0 用户文档》 - 书栈网 · BookStack...

与 MySQL 兼容性对比概览TiDB 100% 兼容 MySQL5.7 协议、MySQL5.7 常用的功能及语法，MySQL5.7 生态中系统的工具(PHPMyAdmin, Navicat, MySQL Workbench、mysqldump、Mydumper/myloader)、客户端等均用于 TiDB。

TiDB 是一款分布式数据库， MySQL5.7 中的部分特性由于工程实现难较大，投入产出比较低等多种原因在 TiDB 未能实现或者仅兼容语法但功能并没有实现，因此使用过程中请特别注意。例如：CREATE TABLE 语句中 ENGINE，仅兼容语法功能并没有实现，因此 TiDB 中没有 ENGINE 这类的概念。

注意：

本页内容仅涉及 MySQL 与 TiDB 的总体差异。关于安全特性、悲观事务模型 相关的兼容信息请查看各自具体页面。

不支持的功能特性存储过程与函数

触发器

事件

自定义函数

外键约束

全文/空间函数与索引

非 ascii/latin1/binary/utf8/utf8mb4 的字符集

SYS schema

MySQL 追踪优化器

XML 函数

X Protocol

Savepoints

列级权限

XA 语法(TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开)

CREATE TABLE tblName AS SELECT stmt 语法

CREATE TEMPORARY TABLE 语法

CHECK TABLE 语法

CHECKSUM TABLE 语法

SELECT INTO FILE 语法

与 MySQL 有差异的特性详细说明

自增 IDTiDB 的自增列仅保证自增且唯一、但不保证自动分配的值的连续性，建议不要将缺省值和自定义值混用，若混用可能会收 Duplicated Error 的错误信息。

TiDB 在工程实现上会在每一个 tidb-server 实例上缓存一段 ID 的值用于给表的自增列分配值，缓存 ID 的个数由表的 AUTO_ID_CACHE 确定，默认值：30000，请特别注意：自增列和_tidb_rowid都会消耗缓存的 ID，如果 INSERT 语句中所要求的连续的 ID 个数大于 AUTO_ID_CACHE 的值时系统会自动调整 AUTO_ID_CACHE 的值以确保该语句能正常执行。

TiDB 可通过 tidb_allow_remove_auto_inc 系统变量开启或者关闭删除列的 AUTO_INCREMENT 属性，删除列属性的语法是：alter table modify 或 alter table change 。

注意：

tidb_allow_remove_auto_inc 要求版本号 >= v2.1.18 或者 >= v3.0.4。

表的 AUTO_ID_CACHE 属性要求版本号 >= v3.0.14 或者 >= v3.1.2 或者 >= v4.0.rc-2。

若创建表时没有指定主键时， TiDB 会使用 _tidb_rowid 来标识行，该数值的分配会和自增列(如果存在的话)共用一个分配器。如果指定了自增列为主键，则 TiDB 会用该列来标识行。因此会有以下的示例情况：

mysql>create table t(idintunique key AUTO_INCREMENT);

QueryOK,0rows affected(0.05sec)

mysql>insertintot values(),(),();

QueryOK,3rows affected(0.00sec)

Records:3Duplicates:0Warnings:0

mysql>select_tidb_rowid,idfromt;

+-------------+------+

|_tidb_rowid|id|

+-------------+------+

|4|1|

|5|2|

|6|3|

+-------------+------+

3rowsinset(0.01sec)

Performance schemaTiDB 主要使用 Prometheus 和 Grafana 来存储及查询相关的性能监控指标，故 Performance schema 部分表是空表。

查询计划EXPLAIN/EXPLAIN FOR 输出格式、内容、权限设置与 MySQL 有比较大的差别，参见理解 TiDB 执行计划。

内建函数支持常用的 MySQL 内建函数，有部分函数并未支持，参考SQL 语法文档。

DDL 的限制Add Index

同一条 SQL 语句不支持创建多个索引。

仅在语法在支持创建不同类刑的索引 (HASH/BTREE/RTREE)，功能未实现。

支持 VISIBLE/INVISIBLE 索引选项，忽略其它索引选项。

Add Column

不支持设置PRIMARY KEY 及 UNIQUE KEY，不支持设置 AUTO_INCREMENT 属性。可能输出的错误信息：unsupported add column '%s' constraint PRIMARY/UNIQUE/AUTO_INCREMENT KEY

Drop Column

不支持删除主键列及索引列，可能输出的错误信息：Unsupported drop integer primary key/column a with index covered。

Drop Primary Key

仅支持删除建表时启用了 alter-primary-key 配置项的表的主键,可能输出的错误信息: Unsupported drop primary key when alter-primary-key is false。

Order By 忽略所有列排序相关的选项。

Change/Modify Column

不支持有损变更，比如从 BIGINT 变为 INTEGER，或者从 VARCHAR(255) 变为 VARCHAR(10)，可能输出的错误信息：length %d is less than origin %d

不支持修改 DECIMAL 类型的精度，可能输出的错误信息：can't change decimal column precision。

不支持更改 UNSIGNED 属性，可能输出的错误信息：can't change unsigned integer to signed or vice versa。

只支持将 CHARACTER SET 属性从 utf8 更改为 utf8mb4

LOCK [=] {DEFAULT|NONE|SHARED|EXCLUSIVE}

仅在语法上支持，功能未实现，故所有的 DDL 都不会锁表。

ALGORITHM [=] {DEFAULT|INSTANT|INPLACE|COPY}

支持 ALGORITHM=INSTANT 和 ALGORITHM=INPLACE 语法，但行为与 MySQL 有所不同，MySQL 中的一些 INPLACE 操作在 TiDB 中的 是INSTANT 操作。

仅在语法上支持 ALGORITHM=COPY，功能未实现，会返回警告信息。

单条 ALTER TABLE 语句中无法完成多个操作。例如：不能用一条语句来添加多个列或多个索引。可能输出的错误信息：Unsupported multi schema change。

Table Option 仅支持AUTO_INCREMENT、CHARACTER SET、COLLATE、COMMENT，不支持以下语法:

WITH/WITHOUT VALIDATION

SECONDARY_LOAD/SECONDARY_UNLOAD

CHECK/DROP CHECK

STATS_AUTO_RECALC/STATS_SAMPLE_PAGES

SECONDARY_ENGINE

ENCRYPTION

Table Partition 分区类型支持 Hash、Range；支持 Add/Drop/Truncate/Coalese；忽略其他分区操作，可能错误信息：Warning: Unsupported partition type, treat as normal table，不支持以下语法:

PARTITION BY LIST

PARTITION BY KEY

SUBPARTITION

{CHECK|EXCHANGE|TRUNCATE|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD|REORGANIZE} PARTITION

ANALYZE TABLEANALYZE TABLE 语句会完全重构表的统计数据，语句执行过程较长，但在 MySQL/InnoDB 中，它是一个轻量级语句，执行过程较短。

视图不支持 UPDATE、INSERT、DELETE 等写入操作。

存储引擎仅在语法上兼容创建表时指定存储引擎，实际上 TiDB 会将元信息统一描述为 InnoDB 存储引擎。TiDB 支持类似 MySQL 的存储引擎抽象，但需要在系统启动时通过--store 配置项来指定存储引擎。

SQL 模式不支持兼容模式，例如： ORACLE 和 POSTGRESQL，MySQL 5.7 已弃用兼容模式，MySQL 8.0 已移除兼容模式。

ONLY_FULL_GROUP_BY 与 MySQL 5.7 相比有细微的语义差别。

NO_DIR_IN_CREATE 和 NO_ENGINE_SUBSTITUTION MySQL 用于解决兼容问题，并不适用于 TiDB。

默认设置字符集：

TiDB 默认：utf8mb4。

MySQL 5.7 默认：latin1。

MySQL 8.0 默认： utf8mb4。

排序规则：

TiDB 中 utf8mb4 字符集默认: utf8mb4_bin。

MySQL 5.7 中 utf8mb4 字符集默认: utf8mb4_general_ci。

MySQL 8.0 中 utf8mb4 字符集默认: utf8mb4_0900_ai_ci。

foreign_key_checks：

TiDB 默认: OFF，且仅支持设置该值为 OFF。

MySQL 5.7 默认： ON。

SQL mode：

TiDB 默认： ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

MySQL 5.7 默认 与 TiDB 相同。

MySQL 8.0 默认 ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION。

lower_case_table_names：

TiDB 默认： 2，且仅支持设置该值为 2。

MySQL 默认如下：Linux 系统中该值为 0

Windows 系统中该值为 1

macOS 系统中该值为 2

explicit_defaults_for_timestamp：

TiDB 默认： ON，且仅支持设置该值为 ON。

MySQL 5.7 默认：OFF。

MySQL 8.0 默认：ON。

日期时间处理的区别

时区TiDB 采用系统当前安装的所有时区规则进行计算(一般为 tzdata 包), 不需要导入时区表数据就能使用所有时区名称，无法通过导入时区表数据的形式修改计算规则。

MySQL 默认使用本地时区，依赖于系统内置的当前的时区规则(例如什么时候开始夏令时等)进行计算；且在未导入时区表数据的情况下不能通过时区名称来指定时区。

注意：

TiKV 采用自己内置时区规则来计算，若系统安装的时区规则与 TiKV 内置的时区规则版本不匹配时，部分情况下可能会发生写入的数据无法读出来的情况。例如，若系统上安装了 tzdata 2018a 时区规则，则在时区设置为 Asia/Shanghai 或时区设置为本地时区且本地时区为 Asia/Shanghai 的情况下，时间 1988-04-17 02:00:00 可以被正常插入 TiDB 3.0 RC.1，但该记录对于特定类型 SQL 则无法再读出来，原因是 TiKV 3.0 RC.1 依据的 tzdata 2018i 规则中该时间在 Asia/Shanghai 时区中不存在(夏令时时间后移一小时)。

TiKV 各个版本内置的时区规则如下：

3.0.0 RC.1 及以后：tzdata 2018i

2.1.0 RC.1 及以后：tzdata 2018e

零月和零日与 MySQL 一样，TiDB 默认启用了 NO_ZERO_DATE 和 NO_ZERO_IN_DATE 模式，不建议将这两个模式设为禁用。尽管将这些模式设为禁用时 TiDB 仍可正常使用，但 TiKV coprocessor 会受到影响，具体表现为，执行特定类型的语句，将日期和时间处理函数下推到 TiKV 时可能会导致语句错误。

类型系统不支持 FLOAT4/FLOAT8。

不支持 FIXED (alias for DECIMAL)。

不支持 SERIAL (alias for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE)。

不支持 SQLTSI* (包括 SQL_TSI_YEAR、SQL_TSI_MONTH、SQL_TSI_WEEK、SQL_TSI_DAY、SQL_TSI_HOUR、SQL_TSI_MINUTE 和 SQL_TSI_SECOND)。