TiDB 面试题库
30 道题- 分类
- 数据库
- 题目数
- 30 道
1 TiDB 是什么?其核心特性有哪些?
答案:
TiDB 是 PingCAP 开源的分布式 HTAP(Hybrid Transactional and Analytical Processing)数据库,兼容 MySQL 协议,适用于混合事务与分析处理场景。
核心特性
| 特性 | 说明 |
|---|---|
| 水平弹性扩展 | 计算层与存储层独立扩展,支持在线加减节点,无需停机 |
| 金融级高可用 | 基于 Multi-Raft 协议,RPO = 0,RTO ≤ 30s |
| 实时 HTAP | 行存(TiKV)+ 列存(TiFlash)双引擎,单一系统同时满足 OLTP 与 OLAP |
| 云原生 | 天然适配 Kubernetes,通过 TiDB Operator 实现自动化部署与运维 |
| MySQL 兼容 | 兼容 MySQL 5.7 协议及大部分语法,应用迁移成本极低 |
适用场景
- 金融行业高可用与强一致性需求
- 海量数据高并发 OLTP
- 实时分析(HTAP)
- 数据汇聚与二次加工
2 TiDB 整体架构是怎样的?各组件职责是什么?
答案:
TiDB 采用计算-存储分离架构,由四个核心组件构成。
graph LR
Client[客户端] --> TiDB1[TiDB Server]
Client --> TiDB2[TiDB Server]
TiDB1 --> PD[Placement Driver]
TiDB2 --> PD
TiDB1 --> TiKV1[TiKV Node]
TiDB1 --> TiKV2[TiKV Node]
TiDB2 --> TiKV2
TiDB2 --> TiKV3[TiKV Node]
TiDB1 --> TiFlash1[TiFlash Node]
TiDB2 --> TiFlash2[TiFlash Node]
PD -.->|调度| TiKV1
PD -.->|调度| TiKV2
PD -.->|调度| TiKV3
TiKV1 -.->|Raft Learner| TiFlash1
TiKV2 -.->|Raft Learner| TiFlash2
| 组件 | 职责 | 有状态 |
|---|---|---|
| TiDB Server | SQL 解析、查询优化、执行计划生成,无状态计算层 | 否 |
| PD(Placement Driver) | 集群元数据管理、时间戳分配(TSO)、Region 调度决策 | 是(etcd) |
| TiKV | 分布式 KV 存储,基于 RocksDB + Raft,承载行存数据 | 是 |
| TiFlash | 列存引擎,通过 Raft Learner 异步复制 TiKV 数据,服务分析查询 | 是 |
3 TiDB Server(SQL 层)的查询处理流程是什么?
答案:
TiDB Server 是无状态 SQL 计算层,负责将客户端 SQL 请求转化为对底层 TiKV/TiFlash 的数据操作。
查询处理流程
graph LR
A[SQL 请求] --> B[Protocol Layer<br/>MySQL 协议解析]
B --> C[Parser<br/>语法解析 AST]
C --> D[Optimizer<br/>查询优化<br/>CBO/RBO]
D --> E[Executor<br/>执行计划]
E --> F{数据来源}
F -->|OLTP| G[TiKV<br/>点查/范围扫描]
F -->|OLAP| H[TiFlash<br/>列存批量扫描]
G --> I[结果聚合返回]
H --> I
核心模块
| 模块 | 功能 |
|---|---|
| Protocol Layer | 兼容 MySQL 协议,管理连接、会话 |
| Parser | 将 SQL 文本解析为 AST(抽象语法树) |
| Optimizer | 基于 RBO(规则优化)和 CBO(代价优化)生成最优执行计划 |
| Executor | 算子执行,采用 Volcano 模型向量化执行 |
| Coprocessor | 部分计算下推到 TiKV/TiFlash 执行,减少网络传输 |
4 PD(Placement Driver)在集群中扮演什么角色?
答案:
PD 是整个 TiDB 集群的"大脑",承担全局调度与元数据管理职责。
核心职责
| 职责 | 说明 |
|---|---|
| 元数据管理 | 维护集群拓扑、Region 分布、Store 状态等全局信息 |
| TSO 时间戳 | 全局唯一单调递增时间戳服务,提供事务一致性保障 |
| Region 调度 | 根据 Store 负载、容量进行 Region 均衡(Balance Leader / Balance Region) |
| 热点调度 | 检测读写热点 Region 并自动打散 |
| Placement Rules | 按 Region 级别控制副本放置策略(拓扑感知、容灾) |
工作原理
- 每个 Region 定期向 PD 上报心跳(Region Heartbeat)
- PD 根据心跳信息构建全局视图,生成调度 Operator 下发到 TiKV
- PD 集群部署奇数个节点(推荐 3 个),通过内嵌 etcd 实现自身 HA
5 TiKV 的存储引擎架构是怎样的?
答案:
TiKV 是分布式事务型 KV 存储引擎,采用 RocksDB + Multi-Raft 架构。
分层架构
| 层级 | 组件 | 说明 |
|---|---|---|
| Raft 层 | Multi-Raft | 通过 Raft 共识协议保证副本间数据一致性 |
| 事务层 | MVCC + 2PC | 基于 Percolator 模型实现分布式事务 |
| KV 引擎 | RocksDB | 本地持久化存储引擎(LSM-Tree) |
| Region 层 | Logical Shard | 数据按 Key Range 切分为 Region(默认 ~256MiB) |
数据模型
- TiKV 将 SQL 表数据映射为
(table_id, row_id)→(column_value)的 KV 对 - 索引映射为
(table_id, index_id, index_value)→row_id的 KV 对 - 所有数据按 Key 有序存储在 RocksDB 中
6 Region 是什么?Region 的分裂与合并机制是怎样的?
答案:
Region 是 TiKV 数据分片与调度的基本单元,是 Raft Group 的载体。
Region 核心属性
| 属性 | 值 |
|---|---|
| 默认大小 | 96MiB(分裂阈值 144MiB) |
| 副本数 | 默认 3 副本 |
| 调度粒度 | Region 是 PD 调度的最小单位 |
分裂(Split)机制
graph LR
A[Region 大小超过阈值] --> B[PD 触发 Split 调度]
B --> C[选定 Split Key]
C --> D[原 Region 一分为二]
D --> E[新 Region 分配副本]
E --> F[PD 重新均衡分布]
合并(Merge)机制
- 当相邻 Region 数据量过小(默认低于 20MiB)时触发
- PD 将两个相邻 Region 合并,减少 Region 数量,降低 Raft 开销
- 合并过程不阻塞读写,通过 Raft 提交特殊日志条目实现
7 TiDB 如何通过 Multi-Raft 保证数据一致性?
答案:
TiKV 采用 Multi-Raft 协议:每个 Region 对应一个独立的 Raft Group,副本间通过 Raft 共识保证强一致性。
Raft Group 结构
| 角色 | 职责 |
|---|---|
| Leader | 处理该 Region 的所有读写请求 |
| Follower | 接收 Leader 日志并应用,不直接服务请求 |
| Learner | 只接收日志不参与投票(用于 TiFlash 复制) |
| Candidate | Leader 选举过程中的候选者 |
关键机制
- Leader 选举:Leader 故障后 Follower 通过超时触发选举,多数派投票选出新 Leader
- 日志复制:写入先持久化到 Leader 的 WAL,复制到多数派 Follower 后提交
- 安全性保证:Raft 保证已提交的日志永远不会被覆盖,RPO = 0
- Lease Read:基于 Leader Lease 实现本地读,避免每次读都走 Raft
8 TiDB 的 MVCC 机制是如何实现的?
答案:
TiKV 在 RocksDB 之上实现 MVCC(Multi-Version Concurrency Control),通过在 Key 中编码时间戳实现多版本管理。
KV 编码格式
| 编码 | 说明 |
|---|---|
Key_start_ts | 数据 Key + 事务开始时间戳(TSO) |
Key_commit_ts | 数据 Key + 事务提交时间戳 |
读写流程
| 操作 | 行为 |
|---|---|
| 写入 | 在新时间戳下写入一个新版本,旧版本保留 |
| 读取 | 根据事务的 start_ts 查找 ≤ start_ts 的最新已提交版本 |
| 删除 | 写入一条 Delete 标记(tombstone),并非物理删除 |
GC(垃圾回收)
- 默认每 10 分钟由 PD 触发一次
- 删除超过
tidb_gc_life_time(默认 10 分钟)的旧版本数据 - GC 以 Region 为单位,通过
unsafe_destroy_range清理
9 TiDB 的分布式事务模型是什么?
答案:
TiDB 采用基于 Percolator 的两阶段提交(2PC)协议实现分布式事务,默认隔离级别为 Snapshot Isolation(SI)。
两阶段提交流程
graph LR
A[事务开始<br/>获取 start_ts] --> B[Prewrite 阶段]
B --> C[锁定所有 Key<br/>写入数据 + Primary Lock]
C --> D[Commit 阶段]
D --> E[提交 Primary Key<br/>获取 commit_ts]
E --> F[异步清理 Secondary Lock]
F --> G[事务完成]
关键概念
| 概念 | 说明 |
|---|---|
| start_ts | 事务开始时从 PD 获取的 TSO,用于 MVCC 快照读 |
| commit_ts | 事务提交时从 PD 获取的 TSO,标记数据版本 |
| Primary Lock | 2PC 中第一个被锁定的 Key,作为事务状态的判定锚点 |
| Secondary Lock | 其余被锁定的 Key,异步提交 |
| Optimistic vs Pessimistic | v3.0 起默认悲观事务模式,执行 DML 时即时加锁 |
隔离级别
- SI(Snapshot Isolation):默认,可重复读
- RC(Read Committed):v4.0 起支持,通过
@@tidb_isolation_read_engines控制
10 悲观事务与乐观事务的区别是什么?
答案:
| 对比维度 | 乐观事务(Optimistic) | 悲观事务(Pessimistic) |
|---|---|---|
| 加锁时机 | Commit 时才检测冲突 | 执行 DML 时即时加锁 |
| 冲突处理 | Commit 阶段冲突则回滚重试 | 等待锁或立即报错 |
| 适用场景 | 冲突率低、短事务 | 冲突率高、长事务 |
| 死锁 | 不存在 | 可能发生,TiDB 自动检测并回滚 |
| 默认模式 | v2.x 默认 | v3.0+ 默认 |
悲观事务加锁机制
-- 悲观事务示例
BEGIN PESSIMISTIC;
SELECT * FROM orders WHERE id = 1 FOR UPDATE; -- 加悲观锁
UPDATE orders SET status = 'paid' WHERE id = 1;
COMMIT;
- 悲观锁通过在 TiKV 写入
Lock记录实现 - 其他事务遇到已加锁的 Key 会等待或返回
KeyIsLocked错误 - 死锁检测基于
wait-for图的周期检测算法
11 TiFlash 的架构设计与工作原理是什么?
答案:
TiFlash 是 TiDB 的列存引擎,通过 Raft Learner 角色异步复制 TiKV 数据,提供实时分析能力。
架构特点
| 特点 | 说明 |
|---|---|
| 列存格式 | 数据按列存储,分析查询只需读取必要列,IO 大幅降低 |
| Raft Learner | 不参与 Raft 投票,不影响 TiKV 写入性能 |
| 异步复制 | 数据从 TiKV 异步复制到 TiFlash,存在毫秒级延迟 |
| 资源隔离 | OLAP 查询路由到 TiFlash,OLTP 查询路由到 TiKV,互不干扰 |
数据同步流程
graph LR
A[Client 写入] --> B[TiKV Raft Leader]
B --> C[TiKV Follower]
B --> D[TiFlash Learner]
D --> E[异步写入列存引擎]
E --> F[OLAP 查询读取]
查询路由
- 优化器根据查询特征自动选择 TiKV 或 TiFlash
tidb_isolation_read_engines参数控制引擎选择- 支持
@@tidb_enforce_mpp强制走 MPP 模式
12 TiDB 如何实现 HTAP?行存与列存如何协同?
答案:
HTAP 的核心是在同一集群中同时维护行存(TiKV)和列存(TiFlash),实现事务与分析的实时融合。
HTAP 协同机制
| 机制 | 说明 |
|---|---|
| 数据同步 | TiFlash 通过 Raft Learner 实时接收 TiKV 变更数据 |
| 一致性保证 | TiFlash 读取时通过校验 safe_ts 保证可读性 |
| 查询路由 | 优化器根据代价估算自动选择行存或列存 |
| MPP 模式 | v5.0 起支持多节点并行计算(MPP),分析性能线性扩展 |
优化器选择策略
-- 强制走 TiFlash 列存
SET @@tidb_isolation_read_engines = 'tiflash';
-- 强制走 MPP
SET @@tidb_enforce_mpp = 1;
-- 自动选择(默认)
SET @@tidb_isolation_read_engines = 'tikv,tiflash,tidb';
MPP 执行模型
- 将分析查询拆分为多个 Stage,分布式并行执行
- 每个 Stage 在不同 TiFlash 节点上并行处理
- 通过 Exchange Operator(Shuffle/Broadcast)在 Stage 间传递数据
13 TiDB 的 MySQL 兼容性如何?有哪些限制?
答案:
TiDB 高度兼容 MySQL 5.7 协议,大部分应用无需修改代码即可迁移。
兼容性矩阵
| 维度 | 兼容程度 | 说明 |
|---|---|---|
| SQL 语法 | 高 | 兼容 SELECT/INSERT/UPDATE/DELETE/DDL |
| 数据类型 | 高 | 支持绝大部分 MySQL 数据类型 |
| 事务 | 高 | SI 隔离级别 ≈ RR,支持悲观/乐观事务 |
| 字符集 | 高 | 支持 UTF-8/UTF8MB4/ASCII/Latin1 |
| 用户权限 | 高 | 兼容 MySQL 权限体系 |
| 连接协议 | 完全兼容 | 兼容 MySQL Client/Driver |
不兼容项
| 限制项 | 说明 |
|---|---|
| 存储引擎 | 不支持 InnoDB 特性(如外键 CHECK) |
| 存储过程/函数 | 部分支持,复杂存储过程有限制 |
| 触发器 | 有限支持 |
| 视图 | 支持但有限制 |
| XA 事务 | 不支持 MySQL XA 语法 |
| 自增 ID | 全局唯一但不连续(可通过 AUTO_ID_CACHE 调整) |
14 TiDB 如何实现水平扩展?
答案:
TiDB 的计算层与存储层完全解耦,支持独立水平扩展。
扩展方式
| 组件 | 扩展方式 | 影响 |
|---|---|---|
| TiDB Server | 增加/减少实例 | 调整计算能力,无状态不影响数据 |
| TiKV | 增加 Store 节点 | PD 自动调度 Region 到新节点 |
| TiFlash | 增加节点 | 增加分析计算能力与列存副本 |
| PD | 增加节点 | 奇数部署(3/5),高可用 |
扩容流程
graph LR
A[新 TiKV 加入集群] --> B[Store 向 PD 注册]
B --> C[PD 检测新 Store]
C --> D[生成 Balance Region 调度]
D --> E[Region 迁移到新 Store]
E --> F[集群重新均衡]
关键参数
- 扩容后 PD 自动触发 Region Balance,数据逐步迁移
- 可通过
pd-ctl scheduler config balance-region调整调度速度 - 支持在线扩缩容,对业务透明
15 TiDB 的高可用与容灾方案是什么?
答案:
TiDB 从多个层面保障高可用:组件级 HA、数据级 HA、跨机房容灾。
高可用架构
| 层级 | 机制 | RPO | RTO |
|---|---|---|---|
| TiDB Server | 无状态,多实例负载均衡 | 0 | 秒级 |
| PD | 内嵌 etcd,Raft 多数派 | 0 | 秒级 |
| TiKV | Multi-Raft 副本,自动故障转移 | 0 | ≤30s |
| TiFlash | Learner 角色,故障不影响 OLTP | — | 分钟级 |
跨机房容灾方案
| 方案 | 架构 | 说明 |
|---|---|---|
| 同城双活 | 2 机房 + 1 仲裁 | 2 个机房各放 2 副本,仲裁机房放 1 副本 |
| 两地三中心 | 主中心 + 同城备 + 异地备 | 同步 + 异步复制 |
| 跨 Region | TiCDC 异步复制 | 延迟较高,适合异地灾备 |
Placement Rules 配置
-- 将某个表的 Region 放置到指定 Store
ALTER TABLE orders PLACEMENT POLICY='local_dc';
16 PD 的调度策略有哪些?
答案:
PD 通过收集 TiKV 上报的心跳信息,生成并下发调度 Operator。
调度类型
| 调度类型 | 触发条件 | 目的 |
|---|---|---|
| Balance Leader | Leader 分布不均匀 | 均衡各节点读负载 |
| Balance Region | Region 分布不均匀 | 均衡各节点存储容量 |
| Hot Region | 检测到读写热点 | 打散热点,避免单点过载 |
| Evict Leader | 节点下线/维护 | 将 Leader 从目标节点迁走 |
| Rule Checker | Placement Rules 变更 | 保证 Region 副本符合放置规则 |
| Split | Region 超过大小阈值 | 分裂 Region,保持合理大小 |
| Merge | 相邻 Region 过小 | 合并 Region,减少 Raft 开销 |
调度流程
graph LR
A[TiKV Region Heartbeat] --> B[PD 收集信息]
B --> C[构建全局视图]
C --> D[调度器计算]
D --> E[生成 Operator]
E --> F[下发到 TiKV]
F --> G[执行 Region 迁移/分裂]
关键配置
leader-schedule-limit:并发 Leader 调度上限region-schedule-limit:并发 Region 调度上限hot-region-schedule-limit:热点调度上限
17 TiDB 的备份与恢复方案有哪些?
答案:
TiDB 提供多种备份恢复工具,覆盖全量、增量、快照级别。
备份工具对比
| 工具 | 类型 | 存储目标 | 适用场景 |
|---|---|---|---|
| BR(Backup & Restore) | 全量/增量快照 | S3/GCS/本地/NFS | 生产级大容量备份 |
| Dumpling | 逻辑导出(SQL/CSV) | 本地/S3 | 小规模数据导出 |
| TiDB Lightning | 数据导入 | 本地/S3 | 大规模数据导入恢复 |
| TiCDC | 增量 CDC | 下游 TiDB/MySQL/Kafka | 实时增量同步 |
BR 使用示例
# 全量备份到 S3
br backup full \
--pd "172.16.5.10:2379" \
--storage "s3://backup/tidb-full/" \
--s3.endpoint "http://minio:9000"
# 恢复全量备份
br restore full \
--pd "172.16.5.10:2379" \
--storage "s3://backup/tidb-full/"
# 增量备份(基于上一次备份的 last-backup-ts)
br backup full \
--pd "172.16.5.10:2379" \
--storage "s3://backup/tidb-incr/" \
--last-backup-ts 431434047666876416
18 TiDB Lightning 的工作原理是什么?
答案:
TiDB Lightning 是高性能数据导入工具,支持将 CSV/SQL dump 数据高速导入 TiDB 集群。
导入模式
| 模式 | 原理 | 速度 | 适用场景 |
|---|---|---|---|
| Local Backend | 直接生成 SST 文件注入 TiKV | 最快(300GB/h+) | 新集群初始化、大规模迁移 |
| TiDB Backend | 通过 SQL 接口写入 | 较慢 | 在线业务集群增量导入 |
| Checker | 仅校验数据合法性 | — | 数据校验 |
Local Backend 流程
graph LR
A[读取 CSV/SQL] --> B[数据编码为 KV]
B --> C[本地排序]
C --> D[生成 SST 文件]
D --> E[上传 SST 到 TiKV]
E --> F[Ingest SST 到 RocksDB]
F --> G[PD 更新 Region 元数据]
关键配置
- 导入期间建议暂停 PD 调度,避免 Region 迁移干扰
region-concurrency控制并发度- 导入完成后执行
ANALYZE TABLE更新统计信息
19 TiCDC 是什么?如何实现变更数据捕获?
答案:
TiCDC(TiDB Change Data Capture)是 TiDB 的增量数据变更捕获工具,实时将 TiDB 的数据变更同步到下游。
架构组成
| 组件 | 职责 |
|---|---|
| Capture | 运行节点,每个 Capture 负责拉取和输出部分变更数据 |
| Owner | 由某个 Capture 选举产生,负责调度和任务分配 |
| ChangeFeed | 同步任务定义,指定源表、下游目标、过滤规则 |
数据流
graph LR
A[TiKV 变更事件] --> B[TiCDC Capture<br/>拉取 Kv Change Log]
B --> C[排序与过滤]
C --> D{下游类型}
D -->|TiDB/MySQL| E[SQL 写入]
D -->|Kafka| F[Avro/Canal/OpenProtocol]
D -->|S3| G[存储为 Parquet/CSV]
使用示例
# 创建同步任务到 MySQL
cdc cli changefeed create \
--pd="http://172.16.5.10:2379" \
--sink-uri="mysql://user:pass@downstream:3306" \
--changefeed-id="sync-to-mysql"
# 创建同步任务到 Kafka
cdc cli changefeed create \
--pd="http://172.16.5.10:2379" \
--sink-uri="kafka://kafka:9092/cdc-topic?protocol=canal"
20 DM(Data Migration)的工作原理是什么?
答案:
DM 是 TiDB 提供的一站式数据迁移工具,支持从 MySQL/MariaDB 全量 + 增量迁移到 TiDB。
核心组件
| 组件 | 职责 |
|---|---|
| dm-master | 调度迁移任务、监控 dm-worker、管理元数据 |
| dm-worker | 执行具体迁移任务,连接上游 MySQL 的 binlog |
| dmctl | 命令行管理工具 |
迁移流程
graph LR
A[上游 MySQL] --> B[全量导出<br/>Mydumper/dumpling]
B --> C[全量导入<br/>Loader/TiDB Lightning]
A --> D[增量同步<br/>读取 Binlog]
D --> E[Relay Log 持久化]
E --> F[Binlog 解析转换]
F --> G[写入下游 TiDB]
关键特性
- 支持 Sharding Merge:多个上游 MySQL 分表合并到 TiDB 一张表
- 支持 Table Routing:上游表名映射到下游不同表名
- 支持 Binlog Event Filter:过滤不需要的变更事件
- 断点续传:增量迁移支持从断点恢复
21 TiDB Operator 在 Kubernetes 中如何部署和管理 TiDB?
答案:
TiDB Operator 是 TiDB 在 Kubernetes 上的自动化运维控制器。
核心 CRD
| CRD | 管理对象 | 说明 |
|---|---|---|
| TidbCluster | 整个 TiDB 集群 | 定义 PD/TiKV/TiDB/TiFlash 各组件规格 |
| TidbMonitor | 监控 | 部署 Prometheus + Grafana 监控 |
| TidbInitializer | 初始化 | 集群启动后执行 SQL 初始化脚本 |
| Backup / Restore | 备份恢复 | 通过 BR 执行备份恢复任务 |
| TidbClusterAutoScaler | 自动伸缩 | 基于 HPA/VPA 的自动扩缩容 |
部署示例
apiVersion: pingcap.com/v1alpha1
kind: TidbCluster
metadata:
name: basic
spec:
version: v7.5.0
pd:
replicas: 3
requests:
storage: "10Gi"
tikv:
replicas: 3
requests:
storage: "100Gi"
tidb:
replicas: 2
运维操作
- 滚动升级:修改
version字段,Operator 自动滚动更新 - 在线扩缩容:修改
replicas字段 - 故障自愈:Pod 异常退出后自动重建
22 TiDB 的监控体系是怎样的?
答案:
TiDB 通过 Prometheus + Grafana 构建完整的可观测性体系,各组件原生暴露 Metrics。
监控组件
| 组件 | 采集目标 | 端口 |
|---|---|---|
| TiDB Server | SQL 执行、连接、慢查询 | 10080 |
| PD | 调度、Region、Store | 2379 |
| TiKV | Raft、RocksDB、CPU/IO | 20180 |
| TiFlash | 列存同步、MPP 执行 | 8234 |
| TiCDC | 同步延迟、吞吐 | 8300 |
关键监控面板
| 面板 | 关注指标 |
|---|---|
| Overview | QPS、延迟、连接数、错误率 |
| TiKV Details | Region 数、Raft 提议速率、RocksDB 压力 |
| PD Schedule | 调度速度、Region 均衡度、Store 容量 |
| TiFlash | 数据同步延迟、MPP 查询性能 |
告警规则示例
# Region 副本数不足告警
- alert: TiKV_Region_Unavailable
expr: pd_regions_status{type="miss_peer_region_count"} > 0
for: 5m
labels:
severity: critical
annotations:
summary: "存在副本缺失的 Region"
23 TiDB 如何进行性能调优?
答案:
TiDB 性能调优涉及 SQL 优化、参数配置、硬件资源三个层面。
SQL 层优化
| 手段 | 说明 |
|---|---|
| 执行计划分析 | EXPLAIN ANALYZE 查看实际执行计划 |
| 统计信息 | 定期 ANALYZE TABLE 更新统计信息,影响 CBO 决策 |
| 索引优化 | 合理创建索引,避免全表扫描 |
| SQL Binding | 固定执行计划,防止执行计划退化 |
-- 查看执行计划
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 100;
-- 绑定执行计划
CREATE SQL_BINDING FOR
SELECT * FROM orders WHERE user_id = 100
USING
SELECT /*+ USE_INDEX(orders, idx_user) */ * FROM orders WHERE user_id = 100;
参数调优
| 参数 | 推荐值 | 说明 |
|---|---|---|
tidb_executor_concurrency | 16 | 算子并发度 |
tidb_distsql_scan_concurrency | 15 | 扫描并发度 |
tikv-server.grpc-concurrency | 4~8 | gRPC 线程数 |
raftstore.apply-pool-size | 2~4 | Apply 线程池 |
raftstore.store-pool-size | 2~4 | Store 线程池 |
24 Placement Rules 是什么?如何使用?
答案:
Placement Rules 是 PD 提供的 Region 级别副本放置策略,支持拓扑感知、容灾隔离和冷热分离。
放置规则结构
{
"group_id": "pd",
"id": "rule1",
"index": 100,
"start_key": "",
"end_key": "",
"role": "voter",
"is_witness": false,
"count": 2,
"label_constraints": [
{"key": "zone", "op": "in", "values": ["z1", "z2"]}
],
"location_labels": ["zone", "host"]
}
核心参数
| 参数 | 说明 |
|---|---|
| role | voter / follower / learner |
| count | 副本数量 |
| label_constraints | 限定副本放置的 Store 标签 |
| location_labels | 副本分布的拓扑层级 |
使用场景
-- 创建放置策略
CREATE PLACEMENT POLICY dc1_followers
FOLLOWERS=2
CONSTRAINTS='[+zone=dc1]';
-- 应用到表
CREATE TABLE orders (...) PLACEMENT POLICY=dc1_followers;
典型场景
- 同城双活:按
zone标签分布副本 - 冷热分离:将历史数据迁移到低配 TiKV
- 合规隔离:指定数据只存储在特定机架
25 TiDB Resource Control 是什么?如何实现资源隔离?
答案:
Resource Control 是 TiDB v7.1 引入的资源管控能力,基于 Resource Unit(RU)实现用户级别的资源配额管理。
核心概念
| 概念 | 说明 |
|---|---|
| RU(Request Unit) | 统一计量单位,综合 CPU/IO/内存消耗 |
| Resource Group | 资源组,绑定到用户/会话,设置 RU 配额 |
| Priority | 资源组优先级(HIGH/MEDIUM/LOW) |
使用方式
-- 创建资源组
CREATE RESOURCE GROUP rg_batch
RU_PER_SEC = 1000
PRIORITY = LOW;
CREATE RESOURCE GROUP rg_online
RU_PER_SEC = 5000
PRIORITY = HIGH;
-- 绑定用户到资源组
ALTER USER batch_user RESOURCE GROUP rg_batch;
ALTER USER app_user RESOURCE GROUP rg_online;
-- 查看资源消耗
SELECT * FROM information_schema.resource_groups;
工作原理
- TiDB Server 本地跟踪 RU 消耗
- 超出配额的请求被限流(throttle)或排队
- 支持 Burstable 模式:允许资源组在配额用完后使用空闲资源
26 TiSpark 是什么?如何与 Spark 集成?
答案:
TiSpark 是 TiDB 的 Apache Spark 插件,允许 Spark 直接读取 TiKV 数据进行离线分析。
架构特点
| 特点 | 说明 |
|---|---|
| 直接读 TiKV | 绕过 TiDB Server,Spark Executor 直连 TiKV |
| 谓词下推 | 过滤条件下推到 TiKV,减少数据传输 |
| 索引支持 | 利用 TiDB 索引加速点查 |
| 兼容 Spark SQL | 在 Spark SQL 中直接查询 TiDB 表 |
配置示例
# spark-defaults.conf
spark.sql.extensions org.apache.spark.sql.TiExtensions
spark.tispark.pd.addresses 172.16.5.10:2379
spark.tispark.tidb.addr 172.16.5.10
spark.tispark.tidb.port 4000
spark.tispark.tidb.user root
spark.tispark.tidb.password ""
使用场景
- TiFlash 不满足的复杂离线 ETL
- 已有 Spark 生态的团队
- 需要 Spark ML 机器学习特征工程
与 TiFlash 的选择
- 实时分析 → TiFlash MPP
- 批量离线 ETL → TiSpark
- 两者可共存
27 TiDB 的在线 DDL 是如何实现的?
答案:
TiDB 的 DDL 操作在线执行,不阻塞读写业务。
DDL 执行模型
| 阶段 | 操作 | 阻塞 |
|---|---|---|
| Schema Change | 修改系统表中的表结构定义 | 否 |
| State 传播 | 等待所有 TiDB 节点同步新 Schema | 否 |
| 数据回填 | 对需要回填的 DDL(如加索引)后台填充数据 | 否 |
DDL 类型
| DDL 操作 | 是否需要回填 | 耗时 |
|---|---|---|
ADD COLUMN | 否 | 秒级 |
ADD INDEX | 是 | 取决于数据量 |
DROP COLUMN | 否 | 秒级 |
DROP INDEX | 否 | 秒级 |
MODIFY COLUMN | 是 | 取决于数据量 |
RENAME TABLE | 否 | 秒级 |
加速 DDL
-- 加速建索引(调大回填并发)
SET @@global.tidb_ddl_reorg_worker_cnt = 16;
SET @@global.tidb_ddl_reorg_batch_size = 1024;
-- 查看DDL进度
ADMIN SHOW DDL JOBS;
28 TiDB 生产环境部署的最佳实践是什么?
答案:
硬件推荐
| 组件 | CPU | 内存 | 磁盘 | 数量 |
|---|---|---|---|---|
| TiDB Server | 16+ 核 | 32+ GB | SSD(系统盘) | ≥2 |
| PD | 8+ 核 | 16+ GB | SSD | 3 |
| TiKV | 16+ 核 | 32+ GB | NVMe SSD(数据盘) | ≥3 |
| TiFlash | 32+ 核 | 64+ GB | NVMe SSD | ≥2 |
| 监控 | 8 核 | 16+ GB | SSD | 1 |
系统配置
# 禁用透明大页
echo never > /sys/kernel/mm/transparent_hugepage/enabled
# 调整 IO 调度器为 none(NVMe)
echo none > /sys/block/nvme0n1/queue/scheduler
# 网络内核参数优化
sysctl -w net.core.somaxconn=32768
sysctl -w net.ipv4.tcp_max_syn_backlog=16384
sysctl -w vm.swappiness=0
TiKV 关键配置
| 参数 | 推荐值 | 说明 |
|---|---|---|
capacity | 磁盘容量 80% | 预留空间给 Raft 和 Compaction |
raftstore.capacity | 同上 | Region 调度参考 |
rocksdb.max-open-files | 40960 | 避免 FD 耗尽 |
readpool.coprocessor.concurrency | CPU 核数 × 0.8 | 协处理器线程 |
29 TiDB 常见故障场景与排查方法有哪些?
答案:
故障排查全景
| 故障类型 | 现象 | 排查命令 |
|---|---|---|
| Region Unavailable | 读写报错 Region unavailable | pd-ctl region check miss-peer |
| 写入延迟高 | 写入 P99 升高 | Grafana → TiKV → Raft Propose |
| 查询慢 | 慢查询日志增长 | SELECT * FROM information_schema.slow_query |
| PD 调度慢 | Region 不均衡 | pd-ctl scheduler show |
| TiFlash 同步延迟 | OLAP 查询数据不一致 | Grafana → TiFlash → Delta data size |
| OOM | TiDB Server 被杀 | 查看 dmesg / 调整 mem-quota-query |
关键排查工具
# 查看 Region 健康状态
pd-ctl region --check
# 查看 Store 状态
pd-ctl store
# 查看 Raft 状态
tikv-ctl raft region -r <region_id>
# 查看慢查询
SELECT query_time, stats, query
FROM information_schema.slow_query
WHERE time > '2026-05-27 00:00:00'
ORDER BY query_time DESC LIMIT 10;
# 分析执行计划
EXPLAIN ANALYZE <慢查询SQL>;
热点问题排查
- 通过
Grafana → PD → Hot Write Region定位热点 Region - 使用
SPLIT TABLE手动分裂热点 Region - 配置
tidb_scatter_region使建表时预打散
30 TiDB 集群升级与版本选择策略是什么?
答案:
版本体系
| 版本类型 | 发布周期 | 生命周期 | 适用场景 |
|---|---|---|---|
| LTS(长期支持版) | 约半年 | 发布后 2 年 | 生产环境首选 |
| DMR(定期里程碑版) | 每季度 | 到下一 DMR 发布 | 测试新特性 |
| ** nightly** | 每日 | — | 开发测试 |
滚动升级流程
graph LR
A[升级前检查] --> B[备份元数据<br/>ETCD / PD]
B --> C[升级 PD]
C --> D[升级 TiKV<br/>逐个滚动]
D --> E[升级 TiDB Server<br/>逐个滚动]
E --> F[升级 TiFlash<br/>逐个滚动]
F --> G[验证集群状态]
G --> H[更新监控组件]
升级方式
| 方式 | 命令 | 说明 |
|---|---|---|
| TiUP 滚动升级 | tiup cluster upgrade <cluster> <version> | 默认方式,逐个节点升级 |
| TiUP 停机升级 | tiup cluster stop && tiup cluster start | 跨大版本升级 |
| TiDB Operator | 修改 spec.version | Kubernetes 环境 |
| 原地替换 | 替换二进制文件 | 紧急 patch |
升级注意事项
- 升级前执行
tiup cluster check检查前置条件 - 大版本升级需查阅 Release Notes 兼容性变更
- 生产环境建议在维护窗口升级
- 保留回滚方案(TiUP 支持
tiup cluster rollback)