想必不少开发者都有过类似经历：受制于传统数据库的局限，处处碰壁。业务流量陡增，分库分表改到崩溃；离线分析查询，半天出不来结果。再加上跨库事务、数据同步、弹性扩缩容等问题，运维开发步步维艰。
直到接触了 TiDB，我才真正理解什么叫 “降维打击”。它作为一款兼容 MySQL 协议的 HTAP 数据库，把 OLTP（事务处理）和 OLAP（分析处理）的能力捏合在了一起，彻底解决了传统架构的痛点。今天，我将从 6 个核心模块，带你把 TiDB 从里到外扒得明明白白，看完你也能给团队做架构选型！
一、TiDB 介绍与架构：一张图看懂
先从这张架构图说起：
1. 【应用接入】
业务系统直接用 MySQL 协议连接 TiDB，不用改代码，无缝兼容。
2. 【计算层：TiDB 集群】
多个无状态 TiDB 节点组成，负责 SQL 解析、优化和执行，可根据负载水平扩容。
3. 【调度大脑：PD 集群】
整个分布式集群的 “中枢”，负责分配时间戳、管理元数据、调度数据分片和负载均衡。
4. 【存储层：TiKV + TiFlash】
- TiKV：事务型 KV 存储，用 Raft 协议保证强一致，支撑 OLTP 业务。
- TiFlash：列式存储，专为 OLAP 分析查询优化，实现事务与分析负载隔离。
为什么这么设计？
传统数据库（如 MySQL）是“计算和存储绑死在一起”的单体架构。表一大、并发一高，加机器都没用——因为数据都在一台机器上。
TiDB 把计算、存储、调度彻底拆开，每一层都可以独立扩容：
- 读并发高了？加 TiDB 节点
- 数据量大了？加 TiKV 节点
- 分析查询慢了？加 TiFlash 节点
这就是云原生数据库的核心能力：按需伸缩，独立扩展。
📌要点：TiDB 采用 Shared-Nothing 架构，每个 TiKV 节点独立负责一部分数据（Region），通过 PD 统一调度，实现真正的水平扩展。这一点和传统的 Shared-Disk 架构（如 Oracle RAC）有本质区别。
二、TiDB 测试环境部署：15分钟跑起来
很多人觉得分布式数据库部署复杂，其实 TiDB 在这方面做得相当友好。
快速部署分为以下几步：
- 环境准备（CentOS 7.x / Ubuntu 18.04+）
- 下载 TiUP 集群管理工具
- 编写拓扑配置文件
- 一键部署
- 验证集群状态
极简部署实操
# Step 1: 安装 TiUPcurl--proto'=https'--tlsv1.2-sSfhttps://tiup-mirrors.pingcap.com/install.sh|sh# Step 2: 启动本地测试集群（单机模拟分布式）tiup playground# 就这么简单，一个命令，本地跑起完整 TiDB 集群！# 输出：# CLUSTER START SUCCESSFULLY# TiDB: 127.0.0.1:4000 (MySQL兼容端口)# TiKV: 127.0.0.1:20160# PD: 127.0.0.1:2379# TiFlash: 127.0.0.1:3930就这么简单。一个命令，本地完整集群全部跑起来。用任何 MySQL 客户端连接127.0.0.1:4000就能操作。
生产环境部署拓扑建议
| 组件 | 最低节点数 | 推荐节点数 | 说明 |
|---|---|---|---|
| PD | 3 | 3 或 5 | 奇数个，Raft 选举需要 |
| TiDB | 1 | 2+ | 无状态，按需扩 |
| TiKV | 3 | 3+ | 默认 3 副本，最少 3 节点 |
| TiFlash | 0 | 1+ | 按需部署 |
| 监控 | 1 | 1 | Prometheus + Grafana |
⚠️提醒：生产环境 PD 和 TiKV 绝对不能部署在同一台机器上——PD 挂了整个集群就瘫痪了，必须独立部署。
三、TiKV 数据存储模块：分布式 KV 的底层密码
这是 TiDB 最核心、也最容易被忽视的一层。很多同学用 TiDB 写了一年 SQL，都不知道底层数据是怎么存的。
TiKV 是 TiDB 的存储核心，也是很多架构师最关心的部分。它的设计细节，直接决定了数据的可靠性和性能。
3.1 核心存储引擎：RocksDB
TiKV 底层基于 RocksDB（优化版的 LevelDB）实现持久化存储，支持高并发的读写和快速的范围查询，完美适配了数据库的存储需求。
3.2 数据分片：Region 机制
TiKV 把数据按连续的 Key 范围分成一个个 Region，每个 Region 就像一个数据分片，默认大小 96MB。比如笔记里的例子，Region1 存储 Key1-Key3，Region2 存储 Key4-Key6，这种分片方式让数据天然具备水平扩展的能力，数据量大了，直接加 TiKV 节点就能扩容。
3.3 强一致保证：Raft 协议
每个 Region 都会有 3 个副本（也可配置 5 副本），组成一个 Raft Group，通过 Raft 协议实现数据的强一致复制。写操作会先写入 Raft 日志，同步到多数副本后才会返回成功，即使某个节点宕机，其他副本也能接管服务，保证数据不丢、服务不中断。
- Leader负责读写
- Follower同步复制
📌要点：Region 分裂是自动触发的——当 Region 大小超过阈值，会自动一分为二，PD 会重新调度副本分布。整个过程对业务完全透明。
3.4 并发控制：MVCC
为了支持高并发读写，TiKV 实现了多版本并发控制（MVCC），每个 Key 会保存多个版本的数据，通过版本号区分不同事务的修改。比如 Key1 会保存多个版本的 Value，读操作可以直接读取对应版本的数据，避免了读写阻塞，大幅提升了并发性能。
3.5 数据模型：从表到 KV 的映射
一张 MySQL 表在 TiDB 内部的存储逻辑：
原始表结构：
┌──────────────────────────────────┐ │ User (id INT PK, name VARCHAR) │ ├──────┬───────────┬───────────────┤ │ id │ name │ _tidb_rowid │ ← 隐式主键 ├──────┼───────────┼───────────────┤ │ 1 │ 张三 │ ... │ │ 2 │ 李四 │ ... │ └──────┴───────────┴───────────────┘ ↓ 映射为 KV 对 ↓ Key: t{TableID}_r{RowID} Value: [col1_val, col2_val, ...] 实际存储: Key: t{53}_r{1} → Value: [1, "张三"] Key: t{53}_r{2} → Value: [2, "李四"] 索引的存储: Key: t{53}_i{IdxID}_{col_val}_{RowID} Value: [空]核心思想：把关系型数据库的表和索引，全部映射成扁平的 Key-Value 键值对。这样不管多复杂的 SQL，到了存储层都是 KV 操作，极度简洁高效。
3.6 Raft 共识协议：怎么保证数据不丢？
这是很多面试必考题，Raft 的流程（在之前课程已讲过，这里不再详细阐述）：
三个关键点：
- 写请求只走 Leader
- 保证写入顺序
- 多数派确认才提交（3 副本时，至少 2 个节点确认）
- 自动故障转移（Leader 挂了，剩余节点自动重新选举）
四、TiDB SQL 层计算引擎：把 SQL 翻译成 KV 操作
很多人好奇：TiDB 是怎么把 SQL 语句，转换成对 TiKV 的读写操作的？这就要靠 SQL 层的计算引擎了。
1. 数据映射：SQL 表 ↔ KV 键值对
TiDB 会把关系型数据库的表数据，转换成 TiKV 能识别的键值对：
- 表数据：Key 是
t[TableID][RowID]，Value 是这一行的列数据，比如上面用户表，张三的记录就会被转换成对应的键值对存储。 - 索引数据：Key 是
t[TableID][IndexID][IndexedColumnsValue]，Value 是对应的 RowID，通过索引可以快速定位到数据行。
这种映射方式，让 TiDB 可以用键值存储的方式，模拟出关系型数据库的完整能力。
2. SQL 执行流程：从查询到结果的旅程
我们执行select count(*) from user where name = '张三'为例，拆解一下执行过程：
- 构造 KV 范围：根据查询条件，生成对应的 Key 范围，比如匹配
name='张三'的索引键范围。 - 读取数据：向 TiKV 发送请求，读取范围内的数据。
- 过滤与聚合：TiDB 对返回的数据进行过滤，只保留符合条件的记录，再执行
count聚合操作。 - 返回结果：把最终结果返回给客户端。
这种计算引擎设计，让 TiDB 既支持简单的 CRUD 操作，也能处理复杂的聚合查询，同时兼容 MySQL 的语法和执行逻辑，业务迁移几乎零成本。
五、PD 数据调度模块：集群的 “智能大脑”
PD 作为 TiDB 集群的元数据管理和调度中心，很多人只知道它是 “元数据存储”，却不知道它的调度能力才是 TiDB 的精髓。
1. 核心职责
- 元数据管理：存储整个集群的节点信息、Region 分布、数据位置，就像集群的 “地图”。
- 数据调度：根据集群负载、节点状态，自动调整 Region 的分布，比如把热点数据迁移到空闲节点，保证集群负载均衡。
- Raft 调度：管理 Raft 副本的分布，保证每个 Region 的副本分布在不同节点，避免单点故障，同时自动进行 Leader 负载均衡，让读写请求均匀分布。
2. 调度场景：解决集群的 “疑难杂症”
- 节点扩容：新增 TiKV 节点时，PD 会自动把其他节点的 Region 迁移过来，无需人工干预。
- 节点故障：某个 TiKV 节点宕机，PD 会自动把该节点上的副本调度到其他节点，保证副本数量足够。
- 热点数据：某个 Region 的读写请求过高，PD 会自动拆分 Region，或者把 Leader 迁移到其他节点，缓解压力。
正是有了 PD 的智能调度，TiDB 集群才能实现真正的 “无人值守” 运维，大幅降低了分布式数据库的运维成本。
| 调度场景 | 触发条件 | 调度动作 |
|---|---|---|
| Leader 均衡 | 某节点 Leader 过多 | 将部分 Leader 迁移到其他节点 |
| Region 均衡 | 某节点 Region 数量过多 | 将部分 Region 副本迁移走 |
| 热点调度 | 某 Region 读写 QPS 过高 | 分裂 Region，分散压力 |
| 故障恢复 | 某 TiKV 节点宕机 | 自动在其他节点补副本 |
| 扩容均衡 | 新节点加入 | 自动迁移部分 Region 到新节点 |
六、OLAP 与 TiFlash 列式存储：HTAP 的 “最后一块拼图”
传统数据库的最大痛点，就是 OLTP 和 OLAP 无法兼顾：事务型数据库跑报表慢，分析型数据库无法支持实时写入。而 TiFlash 的出现，让 TiDB 真正成为了一款 HTAP 数据库。
1. 什么是 TiFlash？
TiFlash 是 TiDB 的列式存储引擎，专门为 OLAP 场景优化。它会异步同步 TiKV 的数据，转换成列式存储格式，大幅提升聚合查询、报表分析的性能。
2. 行存 VS 列存：两种存储的核心差异
- TiKV（行存）：按行存储数据，适合事务型业务，快速读写单行数据，比如订单创建、用户信息修改。
- TiFlash（列存）：按列存储数据，适合分析型业务，比如按用户维度统计订单量、按地区分析销售额，列存可以只读取需要的列，大幅减少 IO，提升查询速度。
3. HTAP 场景：一次数据写入，双场景复用
TiFlash 的典型应用场景：
- 实时报表：业务数据写入 TiKV，TiFlash 自动同步数据，报表查询直接走 TiFlash，无需额外的数据同步和 ETL，报表延迟从小时级降到秒级。
- 混合负载：业务系统正常进行事务操作，同时支持复杂的分析查询，互不影响，彻底告别 “业务库和报表库分离” 的架构。
七、TiDB 落地场景：这些业务用了都说香
聊完架构和模块，很多人会问：“我的业务到底适不适合用 TiDB？” 结合大厂的落地经验，这几个场景，TiDB 的优势拉满：
OLTP 场景：替代分库分表的 MySQL
业务数据量暴涨，MySQL 单库单表撑不住，分库分表又太麻烦？直接上 TiDB，兼容 MySQL 协议，业务代码几乎不用改，就能获得无限的水平扩展能力，金融交易、电商订单、物流轨迹这类高并发事务场景，都能完美适配。
HTAP 场景：事务 + 分析一体化
电商平台的用户行为分析、金融业务的实时风控、零售行业的销售报表，这类业务既要支持实时交易，又要做复杂分析，TiDB+TiFlash 的组合，直接实现 “一套数据，两种用途”，省去了数据同步、ETL 的成本，还能保证数据的实时性。
数据中台场景：统一的数据底座
企业里多个业务系统的数据孤岛严重，数据中台需要一个统一的存储底座，TiDB 兼容 SQL、支持分布式事务、能对接各种大数据生态，完美适配数据中台的建设需求。
写在最后：TiDB 不是 “银弹”，但它解决了大部分架构难题
从业 15 年，我见过太多架构师为了数据库的瓶颈头疼不已。TiDB 的出现，不是说它能解决所有问题，但它用一套架构，解决了传统数据库的扩容瓶颈、事务一致性、OLTP+OLAP 混合负载的痛点，给了我们一个更优雅的选择。
各位看官，看完 TiDB 的架构设计，不知对你手头项目的高可用、高并发架构优化，是否带来了一些新思路？欢迎在评论区聊聊你的看法～论
