【TiDB】01-概述

宣晨光

已于 2024-08-12 10:01:19 修改

阅读量654

点赞数 8

分类专栏： TiDB分布式数据库文章标签： tidb 分布式存储

于 2024-01-24 15:14:42 首次发布

本文链接：https://blog.csdn.net/xcg340123/article/details/135823046

版权

TiDB分布式数据库专栏收录该内容

10 篇文章

订阅专栏

本文介绍了分布式关系型数据库TiDB，它支持HTAP，包括OLTP和OLAP解决方案，具备水平扩展、高可用性、强一致性和ACID事务。核心组件包括元信息管理的PDServer、执行SQL的TiDBServer和存储数据的TiKV/TiFlash。同时提到了使用限制，如不支持复杂操作和表主键自增。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2.2.12、MySQL 弃用功能导致的不兼容问题

分布式关系型数据库

1、支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) ：OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)解决方案

2、无限制的水平扩容或者缩容

3、兼容MySQL ，支持 SQL，对外暴露 MySQL 的网络协议

4、高可用、强一致

5、支持ACID事务

1、整体架构

PD (Placement Driver) Server

整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构

提供全局的分布式事务分配事务 ID

至少 3 个节点构成，拥有高可用的能力，建议部署奇数个 PD 节点

Raft协议，少数服从多数，CP强一致性

TiDB Server

SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。

无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，

请求转发给底层的存储节点 TiKV（或 TiFlash）

TiKV Server 存储节点

TiKV Server：负责存储数据，基本单位是 Region

提供了 SI (Snapshot Isolation) 的隔离级别

默认为三副本，天然支持高可用和自动故障转移。Raft协议

TiFlash 存储节点

特殊的存储节点。在 TiFlash 内部，数据是以列式存储，主要的功能是为分析型的场景加速。

2、使用限制

仅支持SQL基本操作，不支持自定义函数、触发器具体查看

避免使用表主键自增

2.1、不支持的功能特性

存储过程与函数
触发器
事件
自定义函数
全文语法与索引
空间类型的函数（即 GIS/GEOMETRY）、数据类型和索引
非 ascii、latin1、binary、utf8、utf8mb4、gbk 的字符集
MySQL 追踪优化器
XML 函数
X-Protocol
列级权限
XA 语法（TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开）
CREATE TABLE tblName AS SELECT stmt 语法
CHECK TABLE 语法
CHECKSUM TABLE 语法
REPAIR TABLE 语法
OPTIMIZE TABLE 语法
HANDLER 语句
CREATE TABLESPACE 语句
"Session Tracker: 将 GTID 上下文信息添加到 OK 包中"
降序索引
SKIP LOCKED 语法
横向派生表

2.2、与 MySQL 差异的特性说明

2.2.1、自增 ID

TiDB 的自增列既能保证唯一，也能保证在单个 TiDB server 中自增，使用 AUTO_INCREMENT MySQL 兼容模式能保证多个 TiDB server 中自增 ID，但不保证自动分配的值的连续性。建议避免将缺省值和自定义值混用，以免出现 Duplicated Error 的错误。
TiDB 可通过 tidb_allow_remove_auto_inc 系统变量开启或者关闭允许移除列的 AUTO_INCREMENT 属性。删除列属性的语法是：ALTER TABLE MODIFY 或 ALTER TABLE CHANGE。
TiDB 不支持添加列的 AUTO_INCREMENT 属性，移除该属性后不可恢复。
对于 v6.6.0 及更早的 TiDB 版本，TiDB 的自增列行为与 MySQL InnoDB 保持一致，要求自增列必须为主键或者索引前缀。从 v7.0.0 开始，TiDB 移除了该限制，允许用户更灵活地定义表的主键

注意

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

注意

使用 AUTO_INCREMENT 可能会给生产环境带热点问题，因此推荐使用 AUTO_RANDOM 代替。详情请参考 TiDB 热点问题处理。

2.2.2、DDL 的限制

TiDB 中，所有支持的 DDL 变更操作都是在线执行的。与 MySQL 相比，TiDB 中的 DDL 存在以下限制：

使用 ALTER TABLE 语句修改一个表的多个模式对象（如列、索引）时，不允许在多个更改中指定同一个模式对象。例如，ALTER TABLE t1 MODIFY COLUMN c1 INT, DROP COLUMN c1 在两个更改中都指定了 c1 列，执行该语句会输出 Unsupported operate same column/index 的错误。
不支持使用单个 ALTER TABLE 语句同时修改多个 TiDB 特有的模式对象，包括 TIFLASH REPLICA，SHARD_ROW_ID_BITS，AUTO_ID_CACHE 等。
ALTER TABLE 不支持少部分类型的变更。比如，TiDB 不支持从 DECIMAL 到 DATE 的变更。当遇到不支持的类型变更时，TiDB 将会报 Unsupported modify column: type %d not match origin %d 的错误。更多细节，请参考 ALTER TABLE。
TiDB 中，ALGORITHM={INSTANT,INPLACE,COPY} 语法只作为一种指定，并不更改 ALTER 算法，详情参阅 ALTER TABLE。
不支持添加或删除 CLUSTERED 类型的主键。要了解关于 CLUSTERED 主键的详细信息，请参考聚簇索引。
不支持指定不同类型的索引 (HASH|BTREE|RTREE|FULLTEXT)。若指定了不同类型的索引，TiDB 会解析并忽略这些索引。
分区表支持 HASH、RANGE、LIST 和 KEY 分区类型。对于不支持的分区类型，TiDB 会报 Warning: Unsupported partition type %s, treat as normal table 错误，其中 %s 为不支持的具体分区类型。
Range、Range COLUMNS、List、List COLUMNS 分区表支持 ADD、DROP、TRUNCATE、REORGANIZE 操作，其他分区操作会被忽略。
Hash 和 Key 分区表支持 ADD、COALESCE、TRUNCATE 操作，其他分区操作会被忽略。
TiDB 不支持以下分区表语法：
- SUBPARTITION
- {CHECK|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD} PARTITION
更多详情，请参考分区表文档。

`2.2.3、SELECT` 的限制

TiDB 的 SELECT 语法有以下限制：

不支持 SELECT ... INTO @变量 语法。
TiDB 中的 SELECT .. GROUP BY expr 的返回结果与 MySQL 5.7 并不一致。MySQL 5.7 的结果等价于 GROUP BY expr ORDER BY expr。

详情参见 SELECT。

2.2.4、视图

TiDB 中的视图不可更新，不支持 UPDATE、INSERT、DELETE 等写入操作。

2.2.5、临时表

详见 TiDB 本地临时表与 MySQL 临时表的兼容性。

2.2.6、字符集和排序规则

关于 TiDB 对字符集和排序规则的支持情况，详见字符集和排序规则。
关于 GBK 字符集与 MySQL 的兼容情况，详见 GBK 兼容情况。
TiDB 继承表中使用的字符集作为国家字符集。

2.2.7、存储引擎

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

2.2.8、SQL 模式

TiDB 支持大部分 SQL 模式。不支持的 SQL 模式如下：

不支持兼容模式，例如：Oracle 和 PostgreSQL（TiDB 解析但会忽略这两个兼容模式），MySQL 5.7 已弃用兼容模式，MySQL 8.0 已移除兼容模式。
TiDB 的 ONLY_FULL_GROUP_BY 模式与 MySQL 5.7 相比有细微的语义差别。
NO_DIR_IN_CREATE 和 NO_ENGINE_SUBSTITUTION 仅用于解决与 MySQL 的兼容性问题，并不适用于 TiDB。

2.2.9、默认设置

TiDB 的默认设置与 MySQL 5.7 和 MySQL 8.0 有以下区别：

字符集：
- 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。
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，表示表名和数据库名按照在 CREATE TABLE 或 CREATE DATABASE 语句中指定的字母大小写存储在磁盘上，且名称比较时区分大小写。
  - Windows 系统中该值为 1，表示表名按照小写字母存储在磁盘上，名称比较时不区分大小写。MySQL 在存储和查询时将所有表名转换为小写。该行为也适用于数据库名称和表的别名。
  - macOS 系统中该值为 2，表示表名和数据库名按照在 CREATE TABLE 或 CREATE DATABASE 语句中指定的字母大小写存储在磁盘上，但 MySQL 在查询时将它们转换为小写。名称比较时不区分大小写。
explicit_defaults_for_timestamp：
- TiDB 默认：ON，且仅支持设置该值为 ON。
- MySQL 5.7 默认：OFF。
- MySQL 8.0 默认：ON。