TiDB 架构
2025-09-18 16:30:59 0 举报AI智能生成
TiDB 架构
作者其他创作
大纲/内容
2、TiDB Server
2.1 TiDB Server 主要功能
处理客户端的连接
SQL 语句的解析和编译
关系型数据与 KV 的转化
SQL 语句的执行
Online DDL 的执行
垃圾回收
热点小表缓存 V6.0
2.2 TiDB Server 的架构
核心模块
SQL 解析和编译模块
Protocol Layer
Parse
Compile
SQL 执行模块
Executor
DistSQL
KV
事务模块
Transaction
KV
PD 交互模块
PD Client
TiKV 交互模块
TiKV Client
在线 DDL 模块
schema load
startjob
worker
2.3 SQL 语句的解析和编译
SQL解析分为词法分析（生成token）和语法分析（生成AST抽象语法树）
随后通过compile模块进行合法性验证、逻辑优化（列裁剪、子查询下推等）和物理优化（索引选择、表连接顺序等），最终生成执行计划。
逻辑优化基于关系型代数等价规则，物理优化依赖统计信息和数据分布。
逻辑优化基于关系型代数等价规则，物理优化依赖统计信息和数据分布。
2.4 关系型数据与KV的转化
原理图
TIDB将表数据转化为键值对（KV），主键作为key，再加上表编号组成唯一的 id，保证全局唯一，value存储列值。
数据以region为单位存储（默认96MB），超过144MB时分裂为多个region，实现分布式存储。
数据以region为单位存储（默认96MB），超过144MB时分裂为多个region，实现分布式存储。
2.5 读写模块协作
执行计划通过executor执行，复杂查询由DistSQL模块拆解为单表操作，点查直接通过KV模块处理。
2.6 在线DDL相关模块
在线DDL通过job队列实现：所有TIDB Server的starjob接收DDL语句并存入TIKV队列，仅当前owner角色的worker执行job，保证同一时间仅一个DDL操作。
2.7 GC机制与缓存管理
GC（垃圾回收）清理MVCC历史版本数据，默认保留10分钟（gc_life_time参数），由GC leader计算safe point时间点回收过期数据。
2.8 缓存机制
TiDB Server 缓存组成
SQL 结果
线程缓存
元数据,统计信息
TiDB Server 缓存管理
tidb_ mem_quota_query
限制单条SQL内存使用
oom-action
定义超限行为
如超过后是终止 SQL 执行，返回 error，记录日志等
3、TiDB TiKV
3.1 TiKV 架构和作用
TiKV 架构和作用的原理图
数据持久化
分布式一致性
MVCC
分布式事务
Coprocessor
3.2 TiKV 持久化
RocksDB
写入原理
写入原理图
1. 写入流程
(1) Write-Ahead Log (WAL, 预写日志)
所有写入首先顺序追加到 WAL 文件（防止内存数据丢失），确保即使进程崩溃也能恢复数据。
TiKV 中 Raft 日志的持久化依赖此机制。
TiKV 中 Raft 日志的持久化依赖此机制。
(2) MemTable 写入
数据被插入到内存中的 MemTable（基于跳表或哈希表实现），提供 O(1) 写入性能。
TiKV 的 Key-Value 数据（如 Raft 日志、用户数据）会暂存于此。
TiKV 的 Key-Value 数据（如 Raft 日志、用户数据）会暂存于此。
(3) Immutable MemTable
当 MemTable 写满（默认 64MB），转为只读的 Immutable MemTable，并触发后台异步刷盘。
新的写入由新的 MemTable 处理，避免阻塞。
新的写入由新的 MemTable 处理，避免阻塞。
(4) SSTable 生成（刷盘）
后台线程将 Immutable MemTable 按 Key 排序后写入磁盘，生成 Level 0 的 SSTable 文件（Sorted String Table）。
SSTable 文件不可修改，通过追加和合并优化写入性能。
SSTable 文件不可修改，通过追加和合并优化写入性能。
2. 合并与压缩（Compaction）
层级存储：SSTable 分为多个 Level（L0-Ln），数据从 L0 逐步合并到更高层。
Compaction 过程
L0 的 SSTable 可能重叠（影响读性能），通过后台合并生成更高层级的 非重叠 SSTable。
清理过期数据（如 TiKV 中 MVCC 的旧版本），减少存储占用。
清理过期数据（如 TiKV 中 MVCC 的旧版本），减少存储占用。
3. TiKV 中的优化
多 RocksDB 实例
TiKV 为 Raft 日志和 用户数据 分别分配独立的 RocksDB 实例（raftdb 和 kvdb），隔离 I/O 压力。
异步刷盘
通过批量写入和异步 Compaction 降低写入延迟。
Raft 与 RocksDB 协作
TiKV 通过 Raft 协议保证多副本一致性后，再将数据写入 RocksDB 持久化。
4. 特点总结
在 TiKV 中，RocksDB 的 LSM-Tree 设计是其实现高性能写入和低延迟读的关键基础。
WAL：保障数据持久性，崩溃恢复
MemTable：内存高速写入缓冲
LSM-Tree：将随机写转换为顺序写，适合高吞吐场景（如 TiKV 的 OLTP 需求）
Compaction：平衡读写性能，清理冗余数据
MemTable：内存高速写入缓冲
LSM-Tree：将随机写转换为顺序写，适合高吞吐场景（如 TiKV 的 OLTP 需求）
Compaction：平衡读写性能，清理冗余数据
查询原理
查询原理图
1. 查询路径
(1) MemTable 优先查找
查询首先检查内存中的 Active MemTable 和只读的 Immutable MemTable，利用跳表（或哈希表）实现高效点查（O(1) 复杂度）
TiKV 的 Key-Value 数据（如 Raft 日志或用户表数据）会优先从内存中检索。
(2) SSTable 层级搜索
若内存未命中，查询会逐层扫描磁盘上的 SSTable 文件（Sorted String Table）
Level 0：文件按写入顺序存储，可能存在 Key 重叠，需遍历所有文件。
Level 1 及以上：文件按 Key 排序且无重叠，通过二分查找快速定位
Level 1 及以上：文件按 Key 排序且无重叠，通过二分查找快速定位
TiKV 通过 Region 分片管理数据，每个 Region 对应一个 Key Range，进一步缩小查询范围
(3) Bloom Filter 加速
每个 SSTable 内置 Bloom Filter，快速过滤不存在的 Key，减少无效磁盘 I/O
2. TiKV 的分布式扩展
Region 分散存储
数据按 Region 分散在多个 TiKV 节点上，查询时 TiDB Server 通过 PD（Placement Driver）定位目标 Region 所在的 TiKV 节点
多版本并发控制 (MVCC)
TiKV 通过 MVCC 存储数据多版本，支持事务隔离级别（如 Snapshot Isolation），查询时按需读取特定版本
3. 特点总结
在 TiKV 中，RocksDB 的查询性能通过 内存优先、磁盘分层、分布式调度 三者协同实现高吞吐与低延迟
MemTable：内存高速检索，减少磁盘访问
SSTable：分层 通过层级压缩和有序存储优化范围查询性能
Bloom Filter：显著降低无效 I/O，适合点查场景
Region 分片：分布式查询的基础，结合 PD 实现负载均衡
SSTable：分层 通过层级压缩和有序存储优化范围查询性能
Bloom Filter：显著降低无效 I/O，适合点查场景
Region 分片：分布式查询的基础，结合 PD 实现负载均衡
RocksDB Column Families（列簇）
原理图
垂直分片（字段拆分）
逻辑分区：每个 Column Family 是独立的键值命名空间，共享 WAL 但拥有独立的 MemTable/SST 文件
删除数据
LSM-Tree（Log-Structured Merge-Tree）的删除操作是一种逻辑删除机制，主要基于以下原理实现：
逻辑删除（写墓碑标记）
当执行删除操作时，LSM-Tree 不会立即物理删除数据，而是写入一个特殊的墓碑标记（Tombstone）。该标记与被删除的键（Key）关联，表示该键已被删除 [未引用，LSM通用原理]。
合并过程（Compaction）处理墓碑
在后台的 Compaction 操作中，LSM-Tree 会将多层 SSTable（Sorted String Table）文件合并。当遇到墓碑标记时：
若下层 SSTable 存在该键的旧数据：墓碑会覆盖旧数据，二者均被丢弃，实现物理删除 [未引用，LSM通用原理]。
若下层无旧数据：墓碑标记会保留，直到在更高层 Compaction 中被清理 [未引用]。
查询时的处理
读取数据时，若遇到墓碑标记，则直接返回“键不存在”（或根据隔离级别判断是否可见旧版本）。墓碑的优先级高于旧数据 [未引用]。
逻辑删除（写墓碑标记）
当执行删除操作时，LSM-Tree 不会立即物理删除数据，而是写入一个特殊的墓碑标记（Tombstone）。该标记与被删除的键（Key）关联，表示该键已被删除 [未引用，LSM通用原理]。
合并过程（Compaction）处理墓碑
在后台的 Compaction 操作中，LSM-Tree 会将多层 SSTable（Sorted String Table）文件合并。当遇到墓碑标记时：
若下层 SSTable 存在该键的旧数据：墓碑会覆盖旧数据，二者均被丢弃，实现物理删除 [未引用，LSM通用原理]。
若下层无旧数据：墓碑标记会保留，直到在更高层 Compaction 中被清理 [未引用]。
查询时的处理
读取数据时，若遇到墓碑标记，则直接返回“键不存在”（或根据隔离级别判断是否可见旧版本）。墓碑的优先级高于旧数据 [未引用]。
LSM 原理
LSM-Tree（Log-Structured Merge-Tree）是一种高性能的存储引擎设计，广泛应用于数据库系统中（如TiDB的TiKV组件）。
1. 写入机制
日志结构写入：所有写入（插入/更新/删除）首先被顺序追加到内存中的MemTable（跳表或B树结构），避免磁盘随机写。
内存缓冲：MemTable写满后转换为不可变的Immutable MemTable，并异步刷盘为SSTable（Sorted String Table）文件 [未引用，LSM通用原理]。
内存缓冲：MemTable写满后转换为不可变的Immutable MemTable，并异步刷盘为SSTable（Sorted String Table）文件 [未引用，LSM通用原理]。
2. 分层存储（Leveled Compaction）
分层组织：磁盘数据分为多层（L0-LN），每层包含多个有序的SSTable文件，层级越高数据越旧且文件越大。
合并（Compaction）：后台线程将上层小文件合并排序后下沉到下层，减少文件数量和数据冗余 [未引用，LSM通用原理]。
合并（Compaction）：后台线程将上层小文件合并排序后下沉到下层，减少文件数量和数据冗余 [未引用，LSM通用原理]。
3. 删除与墓碑标记
逻辑删除：删除操作写入特殊的Tombstone（墓碑）标记，而非立即物理删除。
Compaction清理：合并时若发现墓碑标记且下层无对应数据，则丢弃该墓碑；若下层有旧数据，则墓碑和旧数据一并清除 [未引用，LSM通用原理]。
4. 读取流程
先查MemTable：检查内存中的活跃MemTable和Immutable MemTable。
逐层查询SSTable：从L0到LN依次查询，利用Bloom Filter快速过滤不存在Key的文件 [未引用，LSM通用原理]。
版本合并：若同一Key在多层存在多个版本，返回最新（时间戳最大）的数据。
逐层查询SSTable：从L0到LN依次查询，利用Bloom Filter快速过滤不存在Key的文件 [未引用，LSM通用原理]。
版本合并：若同一Key在多层存在多个版本，返回最新（时间戳最大）的数据。
5. TiKV中的LSM优化（TiDB相关）
Raft一致性：TiKV基于Raft协议保证多副本数据一致性，LSM存储层与分布式逻辑解耦 56。
多引擎支持：TiKV（LSM+KV）用于OLTP，TiFlash（列存LSM）用于OLAP分析加速 56。
3.3 TiKV 分布式事务
分布式事务
原理
笔记
在第一行加一个主锁，其他行的有一个指向主锁的子锁，其他行更新时，看主锁是否成功了，如果成功了，其他行把宕机之前没有做的补上。
原理图
原理
TiDB 分布式事务的实现原理基于其核心架构设计，结合了 两阶段提交（2PC）、MVCC（多版本并发控制） 和 全局授时（TSO） 机制
1. 事务的原子性与隔离性
原子性（Atomicity）
TiDB 通过 两阶段提交（2PC） 确保跨多个 TiKV 节点的操作要么全部提交，要么全部回滚。由 TiDB Server 协调事务的 PreWrite（预写）和 Commit 阶段
PreWrite
将事务数据写入 TiKV 的未提交状态（带锁）。
Commit
通过 PD（Placement Driver）分配全局唯一的时间戳（TSO）后提交数据，释放锁
隔离级别（Isolation）
TiKV 默认支持 SI（Snapshot Isolation），基于 MVCC 实现
每个事务读取数据时会获取一个全局一致的快照版本（通过 TSO 时间戳）
写入时通过锁机制避免冲突，确保并发事务的可序列化执行
2. 关键组件角色
3. 流程示例
事务开始
TiDB Server 从 PD 获取 start_ts（事务开始时间戳）
数据读写
读操作基于 start_ts 读取快照数据（MVCC）
写操作暂存到内存，PreWrite 阶段写入 TiKV 并加锁
提交阶段
TiDB Server 从 PD 获取 commit_ts，下发 Commit 命令到 TiKV
TiKV 解锁数据并更新可见版本（commit_ts）
若客户端中断，PD 会检测未完成的事务并自动回滚（通过锁的超时机制）
4. 特点总结
线性一致性
依赖 PD 的 TSO 实现全局有序
高可用
TiKV 数据多副本存储，事务状态持久化到 Raft 日志
兼容性
对外暴露 MySQL 协议，支持乐观/悲观事务模式
MVCC
原理
原理图
写不阻塞读
3.4 Raft
原理图
3.5 读与写
数据的写入
1. Raftstore Pool
职责
处理所有 Raft 相关的逻辑，包括 Leader 选举、日志复制和心跳检测
将已提交的 Raft 日志发送到 Apply Pool 进行实际应用
线程模型
通常配置为独立的线程池，避免因 Raft 处理阻塞影响其他操作
2. Apply Pool
职责
将 Raft 日志应用到存储引擎（如 RocksDB）中，完成数据的持久化
确保数据的强一致性，并通过回调通知客户端写入完成
线程模型
与 Raftstore Pool 分离，防止日志应用延迟影响 Raft 协议性能
协作流程示例
写入请求：Leader 节点的 Raftstore Pool 接收请求并生成Raft 日志。
日志复制：通过 Raft 协议同步到多数派副本。
提交应用：已提交的日志由 Apply Pool 异步应用到存储引擎
日志复制：通过 Raft 协议同步到多数派副本。
提交应用：已提交的日志由 Apply Pool 异步应用到存储引擎
原理图
ReadIndex Read
读已 apply 的数据
Lease Read
在 TiDB 分布式数据库中，"lease read"（租约读）是一种优化读取一致性的机制，主要用于减少分布式事务中获取最新数据时的延迟。
Lease Read 的核心作用
避免访问 PD 获取 TSO
默认的强一致性读（如 SELECT FOR UPDATE）需要从 PD (Placement Driver) 获取全局时间戳 (TSO)，可能引入网络延迟。而 Lease Read 允许 TiDB 在一定时间窗口（租约期内）复用本地缓存的最新 TSO，减少 TSO 获取频率
平衡一致性与性能
租约期内（默认 2 秒），TiDB 假设副本数据未发生变化，直接读取本地最新数据。超出租约后，会重新从 PD 获取 TSO 确保强一致性
触发条件
隐式触发：TiDB 会自动判断查询是否适合 Lease Read（如非事务读或低隔离级别场景）。
显式控制：可通过系统变量 tidb_replica_read 调整为 closest-replicas（就近读）或 leader（默认强一致读）来间接影响租约行为
注意事项
不适用于写入冲突场景：如果租约期内有并发写入，仍会触发 TSO 校验。
与 Raft ReadIndex 的关系：Lease Read 是 TiDB SQL 层的优化，而 TiKV 层的 ReadIndex 用于 Raft 线性一致性读，两者协同保障分布式一致性
Follower Read
原理图
follower apply 速度更快
Coprocessor 协同处理器
原理图
原理
计算加速
TiKV 通过协处理器 (Coprocessor) 可以为 TiDB 分担一部分计算：TiDB 会将可以由存储层分担的计算下推。能否下推取决于 TiKV 是否可以支持相关下推。计算单元仍然是以 Region 为单位，即 TiKV 的一个 Coprocessor 计算请求中不会计算超过一个 Region 的数据。
官方文档：https://docs.pingcap.com/zh/tidb/stable/tikv-overview/#coprocessor
功能定位
Coprocessor 是 TiKV 的核心组件，用于在存储层（TiKV）就近处理计算任务（如谓词过滤、聚合运算），避免将大量原始数据传输到 TiDB 层，减少网络开销
工作流程
TiDB Server 生成分布式执行计划后，将计算任务下推（Push Down）到 TiKV 的 Coprocessor 模块
Coprocessor 直接在 TiKV 本地扫描数据并执行过滤、聚合等操作，仅返回处理后的结果集
与 TiFlash 的关系
TiFlash 作为列存引擎，同样通过 Coprocessor 接口支持分析型查询的下推计算（如列裁剪、向量化聚合）
性能优势
通过减少数据传输和分布式节点间的交互，显著提升复杂查询的效率，尤其在 OLAP 场景
4、PD（PlaceMent Driver）
PD 的架构与功能
原理图
PD 至少 3 个节点构成，集成了 etcd raft
TiKV 中的术语
Store
TiKV 实例
TiKV Region
默认 96 M 数据
TiKV Raft Peer
Raft 中的成员
TiKV Leader
负责读写，把写的日志同步给 Follower
TiKV Follower
raft group
leader 和 follower 组成
mutil raft group
多个 raft group 组成
PD 主要功能
整个集群 TiKV 的元数据存储
原理图
PD 告诉 TiDB Server， Leader 在哪个 TiKV 上
leader 可能漂移，region cache 过旧， tikv 告诉真实的 key 在哪，这个叫 back off。
分配全局 ID 和事务 ID
生成全局时间戳 TSO
TSO 分配：概念
physical 多少毫秒
logical time 1 毫秒分成 262144 个 TSO
int64
TSO 分配：过程
TSO 分配：时间窗口
解决性能问题
解决高可用问题
leader TSO [700-703)，[703-706)，follower TSO [700-703)，[703-706)
leader 宕机了
重新选举一个 leader
重新分配 3s 的 TSO [706-709)
[703-706) 不用了
连续性保证不了，有一部分 TSO 丢失了
收集集群信息进行调度
调度：信息收集（通过心跳收集信息）
原理图
调度：生成调度
（根据自身逻辑和关注的点生成 operator）
（根据自身逻辑和关注的点生成 operator）
Balance均衡
Leader
读写均衡
Region
存储均衡
读写均衡
Hot Region
热的 Region 打散到多个 Leader
集群拓扑
缩容
故障恢复
Region merge
合并空的 Region
调度：执行调度（Region 执行调度）
PD 将 operator 发送给 Region
有一个等待队列，PD 按照一定的速度发送 operator 给 Region
Region 接收到 operator 后执行相关的调度
分裂，合并、移动
提供 label，支持高可用
原理图
Region 3 分散在不同数据中心、不同的机柜
label 是 PD 感知 TiKV 的集群拓扑结构
label 的配置
需要在 PD 和 TiKV 节点上配置
zone 代表区域
rack 代表机柜
host 代表服务器
isolaction-level 代表隔离级别
提供 TiDB Dashboard
TSO 的分配
PS 的调度原理
Lable 的作用
5、数据库 SQL 执行流程
描述 DML 语句读写流程
读流程
原理图
TiDB数据库的三个核心组件：TiDB Server负责SQL处理，TiKV负责数据持久化，PD提供时间戳和元数据管理
读流程从获取时间戳开始，经过SQL解析、编译生成执行计划，最终由执行器从RocksDB读取数据返回
写流程
原理图
DML（读/写）语句执行流程
1、初步处理
SQL请求到达TiDB Server后，会向PD获取唯一时间戳（TSO），进行语法解析生成AST语法树，并进入编译（Compile）阶段。
2、读取流程
- 分为点查和非点查两种情况。点查可直接访问KV层获取数据；非点查则需生成执行计划，后续流程涉及distsql、基础- - SQL层及多种Query Execution Plan（如累加Query）的运行。
执行前需从PD或缓存中获取Table Region信息，以确定数据访问位置，并采用region cache机制降低网络负载。
3、写入流程
- 写操作需要先读取数据至TiDB Server内存缓冲区（memo buffer）并进行修改。
- 采用两阶段提交（2PC）模型确保数据一致性：第一阶段（pre-commit），将修改记录和锁写入TiKV；第二阶段（commit），提交事务并释放锁。
- 写请求最终在TiKV内部通过Schedule、Raft Store和Apply模块的协同，在Leader节点和其它副本之间完成日志同步和数据刷盘。
描述 DDL 语句的执行流程
原理图
用户提交的DDL语句会被start drop模块转换为job，并持久化到TiKV的三个队列中（job queue、index queue和history queue）。具体的执行则由具有owner角色的tidb server负责。这揭示了分布式系统中任务分发与执行的解耦设计
worker模块从job queue获取任务执行后放入history queue
DDL（数据定义语言）语句执行流程
特点: 特点在于“在线DDL”，即执行DDL时不阻塞DML操作，保证了高可用性。
基本流程
DDL语句在TiDB Server的编译模块处理后，会被持久化到TiKV中的特定队列（job queue）中。
DDL的执行由Owner角色的TiDB Server负责，该角色是通过周期性选举（由PD控制）产生的。Owner角色由选举产生且轮流担任，确保任务执行的公平性
工作流上，其他节点的start-job模块将DDL作业存入队列，而Owner节点的worker模块会定时从队列中取出jobs进行执行，并将其放入历史队列(history queues)。
特殊情况：“加索引”（ADD INDEX）操作有专用的队列进行处理，与常规DDL分离。
SQL 的 Parse 与 Compile
原理图
通过pd client异步获取数据后，paris模块使用preprocess将SQL转化为AST语法树，随后compile模块进行预处理（检测SQL合法性并识别点查操作）。点查可直接执行跳过优化阶段，显著提升效率；非点查则进入逻辑优化流程，进行外连接转内连接等转换。
SQL优化流程的两个阶段：逻辑优化和物理优
逻辑优化基于关系代数规则进行等价变换，而物理优化则结合统计信息选择最优算子，最终生成物理执行计划。点查场景会直接跳过优化流程，其他情况则进入完整优化链路。
读取的执行
原理图
详细讲解了执行计划获取元数据和表key的流程。关键点在于首次访问必须从PD获取region信息，但后续会缓存在region cache中以减少网络负载。不过缓存可能因region变动而过期，此时会触发back off机制重新从PD获取最新信息。这种设计在性能和准确性之间做了权衡，但网络负载问题仍是潜在瓶颈。
详细讲解了 KV模块的处理逻辑：对于点查（使用唯一索引或主键的查询），直接通过KV模块获取数据，跳过了执行计划生成环节；对于复杂SQL查询，通过base sql层将复杂查询拆解为单表简单查询，实现了SQL与KV的解耦。最后提到KV模块会构建快照对象确保查询数据的时间点一致性。这种分层设计既提升了点查效率，又保持了复杂查询的灵活性。
UnifyRead pool 统一处理点查和复杂查询，按优先级执行。查询会分层访问ROCKS DB，先查blockage，再到mem table和SSD文件。这表明系统设计上注重查询效率和资源分层利用。
解释了数据读取的流程，重点强调了分布式范围扫描并非简单的单表操作，数据可能分散在多个TV的数百个region中，这种设计支持并行查询以提升效率。数据返回后统一通过TV处理
讲解了TKV的数据处理机制，重点强调了算子下推的功能，即TKV不仅能扫描表，还能执行过滤、聚合等操作，减轻tdb server负担。对于多表连接场景，数据需先汇总到T ADB内存处理，揭示了分布式计算的局限性。随后转入写入流程说明，写入时会先将数据读入tidb server缓存，流程与读操作类似但数据不返回用户。这里暗示了读写流程的底层复用性，但写入路径更侧重数据修改的中间状态管理。
写入的执行
原理图
详细讲解了两阶段提交机制，重点强调了事务需要获取两个TSO（事务开始和提交时间戳）。KV模块负责处理事务的读写操作，包括加锁、修改和提交。写请求首先发送到schedule模块处理并发冲突，通过LATCH机制管理冲突写入。无冲突的请求会进入raft store模块进行后续处理。整个流程展示了分布式事务的复杂性，尤其是并发控制部分。
详细讲解了Raft日志持久化流程，强调apply模块负责将日志顺序应用到本地存储，最终数据写入RACKS DB。随后转向DDL执行机制，重点突出在线DDL的特性——执行时不锁表且不影响DML操作。DDL非阻塞特性是该架构的核心优势。DDL相关模块主要集中在tdb server内，涉及协议解析和编译环节。
DDL 的执行
原理图
详细解释了TiDB中DDL语句的执行机制，强调其单线程特性：同一时刻只有owner角色的TiDB server中的worker能执行DDL操作（如加列、建索引），其他worker处于等待状态。这种设计虽然保证了数据一致性，但可能成为性能瓶颈。schema load模块负责加载最新的元数据信息，确保DDL操作的正确性。用户发起的DDL语句会经过解析、编译生成执行计划，最终由start job模块判断当前server是否为owner来决定是否执行。
详细讲解了TiDB中DDL语句的执行流程：非owner节点的DDL会被持久化到job queue，由owner节点的worker定期轮询并执行，完成后移入history queue。值得注意的是加索引操作被单独存放在add index queue，与其他DDL操作区分开来。owner角色通过PD节点控制的轮询机制动态分配，这种设计确保了DDL执行的串行性。
6、HTAP
HTAP 技术
OLTP
支持实时更新的行存
高并发、一致性要求高
每次操作少量数据
OLAP
批量更新的列存
并发数低
每次操作大量数据
OLTP 和 OLAP 带来的问题
传统OLTP与OLAP融合方案存在ETL延迟问题，导致实时分析困难，常见T+1甚至T+2的报表延迟，且多副本数据维护复杂
HTAP 的核心要求
可扩展性
分布式事务
分布式存储
同时支持 OLTP 和 OLAP
实时性
行存和列存数据实时同步
TiDB 的 HTAP 架构
原理图
传统ETL方案存在延迟问题，而当前方案通过raft learner机制实现异步数据转换，既保持OLTP性能又支持实时分析。架构上仅新增TiFlash节点处理列存转换，这种设计在保证系统稳定性的同时实现了技术突破
TiDB 的 HTAP 特性
行列混合
列存（TiFlash）支持基于主键的实时更新，并与行存保持准实时同步，确保一致性读取
TiFlash 作为列存副本
OLTP 与 OLAP 业务隔离
智能选择（CBO 自动或者人工选择）
自动识别走 OLAP 和 OLTP
MPP 架构
MPP 架构
原理图
大量数据的 join 聚合查询
所有 MPP 计算都在 TiFlash 节点内存中完成
存在单点故障风险，一旦节点宕机，整个计算将终止
目前只支持等值连接
Enforce_mpp 帮助验证是否可以使用 MPP
TiDB 5.2版本后新增了enforce_mpp参数，为了解决优化器选择MPP时的灵活性不足问题，会有一个警告，说明不能走 mpp
数据交换的必要性
原因
在分布式数据库中，若无数据交换，连接操作需遍历所有节点，网络负担极大
方案
通过哈希函数（如取模）将相同PID的数据集中到同一节点，使连接操作仅需在本地完成，大幅降低网络开销
可采用更复杂哈希函数减少碰撞
通过并行操作和数据交换优化表连接和聚合性能
核心思路是将计算下推到各个TiFlash节点，避免集中到TiDB Server形成热点
例子：具体通过哈希函数将相同PID或state的数据分发到同一节点，实现本地连接和聚合，显著减少网络传输和计算负载
混合工作负载场景
在线OLTP和分析型BI报表，在没有统一数据库时需要分别对接不同系统。通过智能分派可实现OLTP走MySQL/Oracle，分析型走TiFlash等方案
流式计算场景
传统方案，后端维护了很多数据库。CDC 有一定的延迟性。
TiDB 解决方案
视频教程总结
本次教程深入介绍了KDB的H type技术，重点讲解了其架构、核心特性及MPP架构，并通过示例演示了上述技术如何解决在线事务与实时分析的性能问题。
小结
1. HTAP技术概述
HTAP 是为同时支持在线事务处理（OLTP）和联机分析处理（OLAP）而设计的数据库架构。
传统方案通过将OLTP与OLAP业务分离并使用ETL工具进行数据同步，存在数据延迟和维护成本高等问题。T+1甚至T+2的报表周期无法满足实时分析需求。
一个满足H Type要求的数据库需要具备三大核心能力：高可扩展性（需支持分布式存储与事务）、高一致性（在同一数据源下，行存与列存版本必须强一致）、以及高实时性（OLAP数据需能实现实时或准实时更新）。
2. TiDB数据库的HTAP架构与特性
核心架构：在TiDBDB现有架构基础上引入Type Flash节点。该节点以“learner”角色接入集群，通过Raft协议接收来自TiKV（Key-Value）节点的异步数据复制。
数据转换：复制过来的数据会从行存格式转换为列存格式，从而在同一张表上同时存在行存和列存两个版本。
数据一致性：实现了差异化的准实时同步。例如，Kv的后续可读操作可以立即读取到最新的数据。
智能选择：TiDB Server能够智能识别SQL类型，主动选择最优路径进行查询。例如，事务型SQL经行存查询，分析型SQL经列存查询。用户也可通过参数强制指定查询路径。
MPP架构：这是指多节点并行处理（Massively Parallel Processing）架构，是提升查询性能的核心机制。其特点如下：
计算任务（如过滤、连接、聚合）的规划由tidb server全局协调。
数据过滤、连接、聚合等操作的执行被下推至相应的TiFlash节点执行，从而提升了并行计算能力和效率，避免了中间汇总的瓶颈。
MPP计算参考https://malkov.2021.5.gitee.io/commit/5d7a4dc3a4a444ee9e35e1fd75b7508015f8a7c24d58e1254c9d1dbfc5c8f430/typo-mp。
只支持等值连接和聚合操作。对于复杂连接，可通过enforce_mpp参数强制开启MPP模式。
3. 典型应用场景
混合负载场景：集成处理在线事务处理（如订单、支付）和实时报表分析/BI的需求。例如，线上财务结算走OLTP，实时报表走OLAP，实现统一数据源下的实时分析。
流式计算场景：用于从在线业务系统的数据库中抽取增量数据（通过CDC工具），并进行实时统计与分析。例如，监控订单、UV等指标的变化。
小结
1. HTAP技术概述
HTAP 是为同时支持在线事务处理（OLTP）和联机分析处理（OLAP）而设计的数据库架构。
传统方案通过将OLTP与OLAP业务分离并使用ETL工具进行数据同步，存在数据延迟和维护成本高等问题。T+1甚至T+2的报表周期无法满足实时分析需求。
一个满足H Type要求的数据库需要具备三大核心能力：高可扩展性（需支持分布式存储与事务）、高一致性（在同一数据源下，行存与列存版本必须强一致）、以及高实时性（OLAP数据需能实现实时或准实时更新）。
2. TiDB数据库的HTAP架构与特性
核心架构：在TiDBDB现有架构基础上引入Type Flash节点。该节点以“learner”角色接入集群，通过Raft协议接收来自TiKV（Key-Value）节点的异步数据复制。
数据转换：复制过来的数据会从行存格式转换为列存格式，从而在同一张表上同时存在行存和列存两个版本。
数据一致性：实现了差异化的准实时同步。例如，Kv的后续可读操作可以立即读取到最新的数据。
智能选择：TiDB Server能够智能识别SQL类型，主动选择最优路径进行查询。例如，事务型SQL经行存查询，分析型SQL经列存查询。用户也可通过参数强制指定查询路径。
MPP架构：这是指多节点并行处理（Massively Parallel Processing）架构，是提升查询性能的核心机制。其特点如下：
计算任务（如过滤、连接、聚合）的规划由tidb server全局协调。
数据过滤、连接、聚合等操作的执行被下推至相应的TiFlash节点执行，从而提升了并行计算能力和效率，避免了中间汇总的瓶颈。
MPP计算参考https://malkov.2021.5.gitee.io/commit/5d7a4dc3a4a444ee9e35e1fd75b7508015f8a7c24d58e1254c9d1dbfc5c8f430/typo-mp。
只支持等值连接和聚合操作。对于复杂连接，可通过enforce_mpp参数强制开启MPP模式。
3. 典型应用场景
混合负载场景：集成处理在线事务处理（如订单、支付）和实时报表分析/BI的需求。例如，线上财务结算走OLTP，实时报表走OLAP，实现统一数据源下的实时分析。
流式计算场景：用于从在线业务系统的数据库中抽取增量数据（通过CDC工具），并进行实时统计与分析。例如，监控订单、UV等指标的变化。
7、TiFlash 架构
TiFlash 架构
原理图
异步复制
原理图
Leader 异步发送 Raft 日志给 Learner
不参与 Raft 投票
不参与 Raft 选举
基于主键快速更新
一致性读取
原理图
当客户端在T0时刻写入K=1和K=999后，由于raft log复制延迟，TiFlash 节点尚未同步最新数据。
T1，开始读取 TiFlash 数据，绿色 idex=101 的数据有了，黄色 idx=20。TiFlash 确认 leader raft log 当前写到哪了。
T2，在询问之前，Client 将 key=1, value=100 改为 value= 200
T3，询问两个 leader 最新的 idx
T3，询问到了两个 leader 最新的 idx，125 和 31，TiFlash 等待自己的 idx 到 125 和 31
T4，黄色region成功同步到31号日志，绿色同步到了 idx=124
T5，终于复制了125号日志 ，开始读取K=1的数据，但发现存在两个版本（T0和T2修改）。根据快照隔离规则，T1时刻的读取只能看到T1前完成的T0版本，因此过滤掉T2版本返回T0数据。这揭示了分布式系统中版本冲突的典型处理逻辑，通过时间戳机制保证读取一致性。
快照隔离
智能选择
可将 OLAP 扫描、表扫描等操作路由至 TiFlash，同时通过上下文识别所需的行数据（如索引或过滤）仍从 TiKV 处获取，实现混合式查询优化。
利用列存的特性提升统计分析的性能，同时支持将部分计算（如过滤、聚合）逻辑下推至 TiFlash 节点并行处理。
8、TiDB 6.0 新特性
Placement Rules in SQL
Placement Rules in SQL 之前
跨地域部署的集群，无法本地访问
无法根据业务隔离资源
难以按照业务等级配置资源和副本数
跨地域访问导致的高延迟（如北京用户访问T3表需跨州到纽约）和数据中心内部负载不均（纽约数据中心TiKV5成为性能瓶颈）。这暴露出数据分布策略缺乏灵活性，无法根据业务需求动态调整位置
分布式数据库当前的两个核心痛点：无法根据数据生命周期灵活配置资源（如高频访问的T7表与冷数据T8表被迫共享资源），以及无法实现业务隔离（如纽约用户的三张表集中在同一节点导致性能瓶颈）。通过placement rules方案，现在可以精细控制数据分布：北京用户的T2/T3表实现本地化访问，纽约用户的三张表被隔离到不同节点，T5表还能按需跨数据中心部署。这本质上解决了跨地域访问延迟和资源争抢问题，实现了真正的业务级资源调度。
Placement Rules in SQL 之后
通过placement rules in SQL 功能实现冷热数据分离和资源按业务等级配置。关键点在于通过标签系统精细化控制数据摆放位置，比如将冷数据T8表与热数据T7表物理隔离。
跨地域部署的集群，支持本地访问
根据业务隔离资源
按照业务等级配置资源和副本数
Placement Rules in SQL 的使用
步骤一
实现过程分为三步：打标签（如区域/机柜标识）、指定数据存放位置（精确到实例或区域）、灵活配置副本数。值得注意的是，这种方案既支持精确到服务器的细粒度控制，也兼容仅指定区域的粗放式部署
步骤二
leader角色固定在 TiKV5 服务器，follower角色分散在四个数据中心（北京、东京、上海、伦敦），副本数设置为4+1模式
步骤三
通过create table示例演示了如何将T5表绑定该策略。值得注意的是，前序讨论中提到的冷热数据分离需求（如T8表）在此处得到呼应，当前策略通过region的精细化分布实现了资源隔离。从技术实现来看，标签体系与策略绑定的三步走方案确实降低了操作复杂度。
Placement Rules in SQL 的应用
精细化数据放置，控制本地访问与跨区域访问
指定副本数，提高重要业务的可用性和数据可靠性
将业务按照等级、资源需求或者数据生命周期进行隔离
业务数据整合，降低运维成本与复杂度
热点小表缓存
要求
表的数据量不大（64MB）
只读表或者修改不频繁的表
表的访问很频繁
只读表或者修改不频繁的表
表的访问很频繁
原理
通过内存直接读取来提升吞吐量并避免网络延迟。但核心挑战在于数据一致性问题——当表数据同时在内存和磁盘中存在时，修改顺序会导致读取过期数据。这揭示了缓存方案看似简单实则复杂的本质。
用租房密码的比喻解释了缓存租约机制：5秒租约期内，用户可从缓存读取数据但无法写入，这种设计确保了数据一致性。
详细解释了热点小表缓存的租约机制：读操作在租约期内从缓存读取提升性能，而写操作会被阻塞。
租约到期后，积压的写操作会立即执行，读操作则转向底层存储。这种机制适合查询频繁但极少修改的小表，目前大小限制为64兆。频繁修改会导致性能下降，因为租约到期时读写操作会有短暂延迟。这里揭示了读写分离的设计哲学——通过时间窗口隔离读写冲突，既保证性能又不牺牲一致性。
强调租约长度应根据表的修改频率动态调整，对于极少修改的表可延长至60秒以提升性能。
应用
TiDB 对于每张缓存表的大小限制为 64 MB
适用于查询频繁、数据量不大、极少修改的场景
在租约(tidb_table-cache lease)时间内，写操作会被阻塞
当租约到期 (tidb_ table_cache _lease)时，读性能会下降
不支持对缓存表直接做 DDL 操作，需要先关闭
对于表加载较慢或者极少修改的表，可以适当延长 tidb_ table_cache _lease 保持读性能稳定
内存悲观锁
内存悲观锁的机制和风险
关键在于权衡效率与可靠性：内存悲观锁通过省去网络复制和磁盘IO大幅提升事务效率，但存在锁丢失风险——当leader节点宕机时，未提交事务会强制回滚。这实际上是用一致性保障换取了性能提升，适用于能容忍偶发事务失败的场景。启用方式支持动态参数调整和配置文件重启两种。
原理图
应用
减少事务的延时
降低磁盘和网络带宽
降低 TiKV 的 CPU 消耗
锁丢失问题
TopSQL
新开发的top sql功能将集成在dashboard中，允许用户直接定位到特定TAKV实例上运行的SQL，实时捕获高负载查询。
作用
可视化地展示 CPU 开销最多的 Top 5 类 SQL 语句
支持指定 TiDB Server 及 TiKV实例进行查询
支持统计所有正在执行的 SQL 语句
支持每秒请求数、平均延迟、查询计划等详细执行信息
使用
TiDB Enterprise Manager（TiEM）
重点介绍了TIDB Enterprise Manager如何通过工程化工作流简化数据库管理，从命令行操作转向一键式页面配置，包括集群部署、升级、参数管理、备份恢复等核心功能。这种转变不仅提升效率，更重要的是降低了人为操作失误的风险。
企业中 TiDB 集群管理的问题
数量增长
集群数量
节点数量
组件数量
工具数量
复杂度增长
配置参数复杂度
命令行复杂度
管理接口复杂
企业中 TiDB 集群管理的任务
部署集群
升级集群
参数管理
组件管理
备份恢复与高可用管理
集群监控与告警
集群日志收集
审计与安全
TiDB Enterprise Manager (TiEM)功能
一键部署集群＆多套集群一站式管理
集群原地升级
参数管理
克隆集群＆主备集群切换
9、TiDB Cloud 简介
为什么选择 TiDB
什么是 TiDB Cloud
TiDB Cloud 实现示例
总结
1. TiDB DB Cloud的核心优势与特性
云原生特性：作为分布式数据库，天然具备高可用、水平伸缩（弹性扩缩容）、混合负载支持（OLTP与OLAP）等云原生优势。
多租户架构：支持多租户模型，能为不同用户提供独立的数据隔离空间，保证了数据安全与性能隔离。
对比优势：
效率：用户无需自行采购和部署硬件，可快速创建数据库服务，节约时间和精力。
成本：采用“租用”而非“购买”的模式，按需付费，尤其对突发业务增长有利。
可扩展性：通过简单地添加或移除数据库节点，即可轻松应对业务的发展或收缩。
安全性与稳定性：数据存储在企业VPC内，保障相对安全；同时云服务商有成熟的灾备方案，整体可靠性有保障。
2. TiDB DB Cloud的核心概念与架构
DBaaS (Database as a Service)：TiDB Cloud本质上是在Tidb数据库基础上，封装成的一个数据库管理服务（PasS），方便用户使用。
获取方式：提供两种服务类型——免费的Developer Tier（用于学习和体验）和付费的Dedicated Tier（用于生产环境）。
中心化服务：Cloud架构引入了Central Service，负责集群的计费、告警和监控。
云原生特性：作为分布式数据库，天然具备高可用、水平伸缩（弹性扩缩容）、混合负载支持（OLTP与OLAP）等云原生优势。
多租户架构：支持多租户模型，能为不同用户提供独立的数据隔离空间，保证了数据安全与性能隔离。
对比优势：
效率：用户无需自行采购和部署硬件，可快速创建数据库服务，节约时间和精力。
成本：采用“租用”而非“购买”的模式，按需付费，尤其对突发业务增长有利。
可扩展性：通过简单地添加或移除数据库节点，即可轻松应对业务的发展或收缩。
安全性与稳定性：数据存储在企业VPC内，保障相对安全；同时云服务商有成熟的灾备方案，整体可靠性有保障。
2. TiDB DB Cloud的核心概念与架构
DBaaS (Database as a Service)：TiDB Cloud本质上是在Tidb数据库基础上，封装成的一个数据库管理服务（PasS），方便用户使用。
获取方式：提供两种服务类型——免费的Developer Tier（用于学习和体验）和付费的Dedicated Tier（用于生产环境）。
中心化服务：Cloud架构引入了Central Service，负责集群的计费、告警和监控。
其他
OLTP（联机事务处理）
特点：
▸ 高频率短事务（每次操作<100ms）
▸ 简单查询（通常只涉及单条记录）
▸ 强调ACID（如银行转账必须原子性）
▸ 高频率短事务（每次操作<100ms）
▸ 简单查询（通常只涉及单条记录）
▸ 强调ACID（如银行转账必须原子性）
OLTP = Transaction（交易）→ 日常操作
OLAP（联机分析处理）
特点：
▸ 低频率复杂分析（单次查询可能跑10分钟）
▸ 全表扫描（需要读百万条记录）
▸ 强调吞吐量而非实时性
▸ 低频率复杂分析（单次查询可能跑10分钟）
▸ 全表扫描（需要读百万条记录）
▸ 强调吞吐量而非实时性
OLAP = Analysis（分析）→ 决策支持
题目
TiKV
1.下列属于 TiKV 相关功能的是？（ 选 4 项 ）（ACDF）
A. 系统参数和元数据信息的持久化
B. 产生 TSO（PD）
C. 分布式事务实现
D. MVCC
E. 生成物理执行计划（TiDB Server）
F. 表统计信息的持久化
A. 系统参数和元数据信息的持久化
B. 产生 TSO（PD）
C. 分布式事务实现
D. MVCC
E. 生成物理执行计划（TiDB Server）
F. 表统计信息的持久化
2.关于 TiKV 数据持久化，下列说法不正确的是？（D）
A. RocksDB 有 2 个实例，分别用来持久化 raft log 和 key value 数据
B. RocksDB 中 WAL 用来保证写不丢失
C. 对于删除操作，只需要在原 key value 数据上标记已删除即可
D. RocksDB 中，除了 Level 0 层的数据，其他 Level 都是单一排序持久化的
A. RocksDB 有 2 个实例，分别用来持久化 raft log 和 key value 数据
B. RocksDB 中 WAL 用来保证写不丢失
C. 对于删除操作，只需要在原 key value 数据上标记已删除即可
D. RocksDB 中，除了 Level 0 层的数据，其他 Level 都是单一排序持久化的
C
LSM 原理，不论插入、更新、删除，都是插入一条数据
D
若基于一般LSM-Tree实现原理（非引用内容）：
Level 0（L0）：通常允许SST文件存在键范围重叠（无序），因MemTable直接刷盘生成
Level 1及以上（L1-LN）：通过Compaction保证每层内SST文件键范围有序且不重叠
Level 0（L0）：通常允许SST文件存在键范围重叠（无序），因MemTable直接刷盘生成
Level 1及以上（L1-LN）：通过Compaction保证每层内SST文件键范围有序且不重叠
PD
1.下列关于 PD（Placement Driver）架构和功能正确的是？（B）
A. 访问 PD 集群中的任何一个节点都可以获得 TSO
B. TiKV 会周期性地向 PD 上报状态
C. PD 会周期性地查询 TiKV 的状态，不需要 TiKV 上报，目的是为了高效
D. PD 的调度功能只能平衡 region 的分布，无法对 leader 进行调度
A. 访问 PD 集群中的任何一个节点都可以获得 TSO
B. TiKV 会周期性地向 PD 上报状态
C. PD 会周期性地查询 TiKV 的状态，不需要 TiKV 上报，目的是为了高效
D. PD 的调度功能只能平衡 region 的分布，无法对 leader 进行调度
2.关于 label ，下列说法不正确的是？（C）
A. label 的本质是个调度系统，可以人为控制 region 副本的存放位置
B. label 需要在 PD 和 TiKV 上进行配置
C. isolation-level 要和数据中心（DC）对应，这样可以获得最大的可用性（不一定要和 DC 对应，可能只有 host）
D. 如果某个 region 的所有副本不可用，有可能造成整个 TiDB 数据库不可用
A. label 的本质是个调度系统，可以人为控制 region 副本的存放位置
B. label 需要在 PD 和 TiKV 上进行配置
C. isolation-level 要和数据中心（DC）对应，这样可以获得最大的可用性（不一定要和 DC 对应，可能只有 host）
D. 如果某个 region 的所有副本不可用，有可能造成整个 TiDB 数据库不可用
HTAP
1.下面属于 HTAP 场景特点的是？（请选择 3 项）（CDE）
A. 在故障恢复方面可以做到 RPO = 0
B. 支持分区特性
C. 支持在线业务高并发
D. 同时支持 OLTP 和 OLAP 业务
E. 能够读取到一致性的数据
A. 在故障恢复方面可以做到 RPO = 0
B. 支持分区特性
C. 支持在线业务高并发
D. 同时支持 OLTP 和 OLAP 业务
E. 能够读取到一致性的数据
2.关于 MPP 架构，下列说法不正确的是？（B）
A. MPP 架构的中间结果都在内存中
B. MPP 架构可以作用于 TiKV 和 TiFlash 上的数据
C. MPP 架构目前不支持非等值 join
D. MPP 架构可以对聚合、JOIN 等操作加速
A. MPP 架构的中间结果都在内存中
B. MPP 架构可以作用于 TiKV 和 TiFlash 上的数据
C. MPP 架构目前不支持非等值 join
D. MPP 架构可以对聚合、JOIN 等操作加速
TiFlash
1.下面属于 TiFlash 核心特性的是？（请选择 3 项）（CDE）
A. 采用行存 + 列存的混合存储方式（列存）
B. region 支持 raft 投票和选举（learner 不投票和选举）
C. TiFlash 采用异步复制来保证和 TiKV 一致
D. 在 TiKV 上写入数据成功后，在 TiFlash 上可以一致性读取
E. CBO 基于成本选择在 TiFlash 或者 TiKV 上执行 SQL
A. 采用行存 + 列存的混合存储方式（列存）
B. region 支持 raft 投票和选举（learner 不投票和选举）
C. TiFlash 采用异步复制来保证和 TiKV 一致
D. 在 TiKV 上写入数据成功后，在 TiFlash 上可以一致性读取
E. CBO 基于成本选择在 TiFlash 或者 TiKV 上执行 SQL
2.关于 TiFlash 的使用，描述不正确的是？（B）
A. TiFlash 不善于处理高并发，QPS 一般不应过高
B. SQL 语句执行中，要不然数据完全从 TiKV 中读取，要不然完全从 TiFlash 中读取
C. MPP 中表连接前的过滤和交换完全是在 TiFlash 节点上完成的
D. 在读取 TiFlash 中数据的时候，我们需要通过 TiKV 中的数据确认一致性
A. TiFlash 不善于处理高并发，QPS 一般不应过高
B. SQL 语句执行中，要不然数据完全从 TiKV 中读取，要不然完全从 TiFlash 中读取
C. MPP 中表连接前的过滤和交换完全是在 TiFlash 节点上完成的
D. 在读取 TiFlash 中数据的时候，我们需要通过 TiKV 中的数据确认一致性
TiDB 6.0 新特性
1.对于 TiDB v6.0 新特性描述正确的为？（请选择 3 项）（BDE）
A. 小表缓存支持 DML 和 DDL 语句操作
B. 内存悲观锁功能可以起到降低网络带宽的作用
C. 当某个 TiKV 实例的 IO 过高，我们可以通过 Top SQL 监控到其上 IO 最高的 5 类 SQL 语句
D. TiDB Enterprise Manager（TiEM）可管理多套集群
E. 我们可以通过 Placement Rules in SQL 功能增加某些重要业务表的副本数
A. 小表缓存支持 DML 和 DDL 语句操作
B. 内存悲观锁功能可以起到降低网络带宽的作用
C. 当某个 TiKV 实例的 IO 过高，我们可以通过 Top SQL 监控到其上 IO 最高的 5 类 SQL 语句
D. TiDB Enterprise Manager（TiEM）可管理多套集群
E. 我们可以通过 Placement Rules in SQL 功能增加某些重要业务表的副本数
2.下列哪些情况可能适宜开启小表缓存？（请选择 2 项）（BC）
A. 表数据量小于 128 MB
B. 频繁读取的热点小表
C. 只读的热点小表
D. 读取和修改都非常频繁的热点小表
A. 表数据量小于 128 MB
B. 频繁读取的热点小表
C. 只读的热点小表
D. 读取和修改都非常频繁的热点小表
TiDB Cloud 简介
1.下面对于 TiDB Cloud 描述，正确的为？（请选择 4 项）（ADEF）
A. 属于 DBaaS 服务
B. 数据属于客户自己和云服务厂商
C. 都具有 VPC Peer
D. 属于多租户架构
E. 不仅支持自动备份还支持手动备份
F. 支持一定的删除后还原
A. 属于 DBaaS 服务
B. 数据属于客户自己和云服务厂商
C. 都具有 VPC Peer
D. 属于多租户架构
E. 不仅支持自动备份还支持手动备份
F. 支持一定的删除后还原
2.关于 Developer Tier 和 Dedicated Tier，下面说法正确的为？（请选择 2 项）（CD）
A. 都支持 VPC Peer
B. 都支持横向扩容和缩容
C. 都支持 TiFlash 节点
D. 都具有多租户特性
E. 都具有高可用性
A. 都支持 VPC Peer
B. 都支持横向扩容和缩容
C. 都支持 TiFlash 节点
D. 都具有多租户特性
E. 都具有高可用性
0 条评论
下一页
