数据库教程FGMT79：国产数据库-TiDB分布式数据库工程师培训实战教程（PB级大数据平台、大规模分布式集群架构）
数据库教程FGMT79：国产数据库-TiDB分布式数据库工程师培训实战教程（PB级大数据平台、大规模分布式集群架构）
## 一、前言与风哥教程本文大纲介绍
风哥教程本文是本套风哥教程中面向国产分布式数据库方向的一篇系统性实战文档，对应 TiDB 分布式数据库工程师培训实战教程（PB级大数据平台、大规模分布式集群架构）的全部主干内容。风哥在编写风哥教程本文时，刻意把篇幅按”少量理论铺垫、大量动手操作”的方式组织：先用理论把 TiDB 的体系架构、存储原理、计算原理与调度原理讲透，再用完整的环境准备、单机部署、生产 OLTP 集群部署、扩缩容、负载均衡、HTAP 集群、版本升级、两地三中心以及日常运维管理把工程师必须亲手完成的操作逐条落地。
风哥教程本文面向的读者是 IT 从业人员、数据库工程师、DBA、数据架构师、大数据工程师与 IT 运维人员。阅读风哥教程本文不需要读者具备分布式数据库的先验知识，但需要读者熟悉 Linux 基本操作、MySQL 协议与 SQL 基础，因为 TiDB 兼容 MySQL 5.7 协议，绝大多数 MySQL 客户端、连接串、JDBC 驱动与中间件可以直接沿用，应用侧基本不需要改写业务 SQL。
风哥教程本文的大纲与本套风哥教程的学习顺序保持一致，共分为七个部分：
1. TiDB 分布式数据库基础知识：数据库系统分类、TiDB 数据库介绍、TiDB 应用场景、TiDB 版本发展、TiDB 体系架构介绍。
2. TiDB 分布式数据库项目实战环境准备：操作系统规划、内核参数、文件系统、时间同步、免密登录、目录与磁盘规划。
3. TiDB 分布式数据库安装部署——单机测试环境：使用 TiUP Playground 在单台 64G 内存 8CPU 主机上快速拉起一套可验证的测试集群。
4. TiDB 分布式数据库集群安装部署：生产环境 OLTP 十节点集群部署、TiDB/PD/TiKV 扩容与收缩、负载均衡访问实现、生产环境 HTAP 十四节点集群、TiCDC/TiFlas-h 扩容与收缩、集群版本升级、两地三中心集群安装。
5. TiDB 数据库核心架构原理深入解析：存储原理、计算原理、调度原理。
6. TiDB 数据库日常维护与管理入门：数据类型与 SQL 基本操作、基本功能、目录与配置文件、系统表、用户与权限、备份与恢复、日常运维检查与诊断、监控与告警、性能调优、相关工具。
7. 风哥针对本文总结。
风哥特别说明：风哥教程本文所有示例均按单节点 64G 内存、8CPU 的规格给出配置参数；所有安装路径统一使用 /fgedudb；示例数据库名、实例名、用户名统一使用 fgedudb / fgedudb / fgedu；示例主机名为 fgedu-net-cn1、fgedu-net-cn2。读者在自己的环境中复现时，只需把 IP、磁盘容量与业务库名替换为自身环境的值，命令结构与参数取值可以直接沿用。
## 二、理论篇：TiDB 分布式数据库核心知识
### 2.1 数据库系统分类与 TiDB 的定位
要理解 TiDB，先要把数据库系统的分类讲清楚。风哥教程本文按数据模型与处理方式把常见数据库分为三类。
第一类是传统关系型数据库（RDBMS），如 MySQL、Oracle、PostgreSQL，以结构化表、事务、SQL 为核心，擅长 OLTP（在线事务处理），但单机容量、内存与连接数存在天花板，水平扩展需要依赖分库分表中间件，业务层要自己处理路由、聚合、分布式事务，改造成本高。
第二类是 NoSQL 数据库，如 Redis、MongoDB、HBase，为特定模型（键值、文档、宽列）做了专项优化，牺牲了部分事务能力与 SQL 通用性换取扩展性，适合缓存、文档存储、海量宽表场景，但无法直接承载复杂关联查询与严格事务。
第三类是分布式分析型数据库（MPP），如 GreenPlum、ClickHouse，擅长 OLAP（在线分析处理），吞吐高、聚合强，但不适合承载高并发短事务，一般作为数仓侧引擎存在。
TiDB 是 PingCAP 公司自主设计、研发的国产开源分布式数据库，定位是一款融合型 HTAP（Hybrid Transactional/Analytical Processing）分布式数据库，同时支持 OLTP 在线事务处理与 OLAP 在线分析处理，具备水平扩容或缩容、金融级高可用、实时 HTAP、云原生等特性，并且兼容 MySQL 5.7 协议和 MySQL 生态。这意味着应用侧几乎不需要改写 SQL 就能把业务从 MySQL 迁移到 TiDB，而底层的存储与计算却天然是分布式的，不需要业务层做分库分表，也不需要单独建设一套 ETL 链路去把交易数据同步到分析库。
从部署形态看，TiDB 支持物理机、虚拟机、私有云与公有云，既可以像本套风哥教程这样在 RHEL 兼容系统上用 TiUP 裸机部署，也可以在 Kubernetes 上用 Operator 管理。数据层面，TiDB 把计算（TiDB Server）、调度（PD）、存储（TiKV）、列存分析（TiFlas-h）、变更订阅（TiCDC）拆成独立组件，各自独立扩缩容，这是它能同时覆盖交易与分析的根本原因。
与传统分库分表方案对比，MySQL 分片中间件把路由逻辑放在应用侧或代理层，扩容需要数据迁移、跨片事务由应用补偿，查询跨片时还要合并结果；TiDB 把分片（Region）、路由、事务、聚合全部下沉到内核，应用看到的仍是一张完整的表，扩容只需要加节点、由 PD 自动搬数据。与纯 NewSQL 方案对比，TiDB 的差异化在于兼容 MySQL 生态、自带 HTAP 列存与增量订阅，迁移成本低、组件闭环完整。风哥提醒读者：选型时不要把 TiDB 当成”更快的 MySQL”，它的价值在于弹性与高可用，点查延迟与单机 MySQL 相比存在网络与 Raft 复制的固有开销，业务设计上应尽量让事务短小、热点分散。
### 2.2 TiDB 应用场景与版本发展
TiDB 的典型应用场景包括：业务数据量持续增长、单机 MySQL 容量与性能逼近瓶颈的 OLTP 系统；需要同时承载交易与报表、希望避免”交易库加数仓”两套链路重复建设的 HTAP 系统；对高可用与跨机房容灾有硬性要求的金融级业务；需要弹性扩缩容、应对流量波峰的互联网业务；以及 PB 级大数据平台中对结构化数据提供统一 SQL 入口的场景。截至 2026 年，TiDB 已被 4000 余家不同行业的企业应用在实际生产环境，覆盖互联网、游戏、银行、保险、证券、航空、制造业、电信、新零售、政府等行业，并在海外市场落地。
从版本发展看，TiDB 经历了从早期原型到成熟生产版本的多个阶段。早期版本以 TiDB Server + PD + TiKV 三件套为核心，解决”可水平扩展的事务库”问题，重点是 Raft 复制与分布式事务；中期引入 TiFlas-h 列存引擎，补齐 HTAP 能力，让同一份数据同时服务交易与实时分析；随后加入 TiCDC 增量数据订阅组件、Placement Rules 精细化副本放置、br 备份恢复工具、TiUP 集群管理工具，把集群的日常生命周期管理标准化；近年版本进一步完善了异步提交、资源管控（Resource Control）、临时表、JSON 增强、数据校验、矢量类型与两地三中心容灾能力。风哥教程本文的实战命令以 6.5 LTS 系列为基线，参数命名与行为在 6.x 与 7.x 之间基本一致，读者可按自身环境选择对应版本号，升级路线需遵循官方兼容矩阵，不建议跨大版本直接跳跃。
版本时间线方面，早期 1.x 与 2.x 完成三件套雏形与 Raft 复制验证；3.x 引入更成熟的分布式事务与统计信息；4.x 完善 Coprocessor 下推与权限体系；5.x 引入 TiFlas-h 实时列存与 MPP，HTAP 能力成型；6.x 补齐资源管控、临时表、异步提交与两地三中心 Placement Rules；7.x 在性能、向量检索、数据校验与运维自动化上继续演进。生产选型优先选 LTS（长期支持）版本，避免使用未发布的 nightly 构建；升级前先在测试环境跑一遍业务回归，确认 SQL 兼容、慢查询无回退再推进。
典型应用场景有四类：一是金融交易系统，要求强一致、高可用、可水平扩展，账户与订单数据用 TiKV 三副本保证不丢；二是电商与零售，大促期间读写洪峰靠弹性扩容承接，订单与库存表天然适合分布式分片；三是物联网与日志平台，数据量随时间线性增长，TiKV 的 Region 自动分裂让存储容量不再受单机限制；四是实时数仓与报表分析，业务数据同时落在 TiKV 做交易、落在 TiFlas-h 做实时聚合，避免传统架构里 ETL 延迟。风哥提醒：不要为了”分布式”而上 TiDB，数据量小、并发低、强依赖存储过程与特殊语法的业务，单机 MySQL 仍然更省。
### 2.3 TiDB 体系架构
TiDB 在初期就从内核设计上将整体架构拆分成多个模块，各模块之间互相通信，组成一套完整的分布式数据库系统。风哥教程本文按职责把架构拆为五个核心组件，并给出各组件的默认端口与 64G 内存 8CPU 规格下的角色建议。
**TiDB Server（计算层）**：无状态的 SQL 计算节点，负责接收客户端 MySQL 协议连接（默认端口 4000）、解析 SQL、生成执行计划、与 TiKV 交互读写数据，内部状态只保存在连接与会话中。TiDB Server 本身不存数据，可以任意水平增加节点，前端通过负载均衡把连接分发到多个 TiDB 实例。每个 TiDB 进程默认占用内存上限建议设为 48GiB，给操作系统与日志留出余量。
**PD（Placement Driver，调度层）**：集群的元数据管理与调度大脑，默认客户端端口 2379、节点间通信 2380，存储集群拓扑、Region 路由信息，负责副本分配、负载均衡、全局时间戳（TSO）分配。PD 自身以 Raft 协议组成高可用小集群，生产环境通常 3 节点或 5 节点，同机房可部署 3 节点，跨机房按两地三中心设计 5 节点。
**TiKV（存储层）**：分布式键值存储引擎，默认服务端口 20160、状态端口 20180，基于 Raft 协议做多副本强一致复制，数据按 Region（默认约 96MiB 一个区间）切分，每个 Region 是 Raft 复制单元。TiKV 内部使用 LSM-Tree 组织数据，配合 MVCC 实现多版本并发控制，64G 内存规格下 memory-limit 建议设为 48GiB，其中 block-cache 占 30GiB 左右。
**TiFlas-h（列存引擎）**：以 Raft learner 方式实时同步 TiKV 的行存数据，转成列存格式，对外提供 9000（TiDB 协议）、10080（HTTP 状态）、3930（gRPC）等端口，为 OLAP 查询提供 MPP 执行能力，是 HTAP 架构的关键组件。
**TiCDC（变更数据捕获）**：默认端口 8301（gRPC）、8302（HTTP），订阅 TiKV 的增量变更日志，把数据变更实时投递到下游 MySQL、Kafka、TiDB 或对象存储，用于异地容灾、数据同步与归档。
整体数据流是：应用通过 MySQL 协议连接 TiDB Server；TiDB Server 把 SQL 改写为对 Key-Value 的读写请求，通过 PD 获取 Region 路由，直接访问持有对应 Region 的 TiKV 节点；分析型查询下推到 TiFlas-h 走 MPP；增量变更由 TiCDC 捕获并投递下游。监控体系由 Prometheus 采集各组件 metrics，Grafana 展示面板，Alertmanager 负责告警分发，这套监控组件由 TiUP 在部署时一并拉起。
64G 内存 8CPU 规格下的资源分配建议：TiKV 节点把物理内存的七成左右留给 block-cache 与进程上限，其余留给操作系统页缓存；TiDB 节点单条查询内存上限 8GiB、进程上限 48GiB，避免大查询把节点拖垮；PD 节点负载很轻，2 核 8G 即可满足，64G 机器上属于富余；TiFlas-h 节点列存压缩比高，内存主要用于 MPP 计算，建议 30GiB 上限。网络方面，TiDB 与 TiKV 之间走 gRPC，万兆网卡是生产底线，跨机房链路要单独评估 Raft 复制带宽。
### 2.4 存储原理深入解析
TiKV 的数据组织以 Region 为基本单位。一张表的数据先按主键或二级索引编码成 Key，再按 Key 区间切分成若干 Region，每个 Region 默认大小约 96MiB，超过阈值会被 PD 调度拆分，过小的相邻 Region 会被合并。每个 Region 在多个 TiKV 节点上保存副本（默认 3 副本），副本之间通过 Raft 协议复制：Leader 负责读写，Follower 只复制日志，Leader 故障时由多数派（Quorum）投票选出新 Leader，保证强一致与高可用。Raft 日志以 Append Entry 方式顺序写入，提交到多数派后才对客户端可见，这就是 TiDB 事务”多数派写成功即成功”的理论基础。
底层存储采用 LSM-Tree（Log-Structured Merge-Tree）：写请求先写入 WAL（Write Ahead Log）再进入内存表 MemTable，内存表写满后 Flus-h 为 SSTable 文件落盘，后台 Compaction 合并多层 SSTable、清理过期版本与删除标记。Compaction 分为 Minor、Major 级别，直接影响磁盘写放大，64G 内存 8CPU 规格下建议适当调大 write-buffer 数量与后台并发，避免 Compaction 积压造成写入延迟抖动。
TiKV 同时实现 MVCC（多版本并发控制）：每行数据携带版本号，写操作不覆盖旧值而是写入新版本，读操作按时间快照读到对应版本，从而实现”读写不互相阻塞”的隔离能力。事务采用两阶段提交（2PC），由 TiDB 协调、PD 分配全局单调递增的 TSO 作为事务版本号，保证分布式事务的原子性与隔离性。默认隔离级别为 SI（快照隔离），在大多数场景下等价于可重复读，脏读、不可重复读被禁止，写冲突由重试机制处理。
Raft 选举与快照补充说明：每个 Region 的 Leader 负责接收写请求并把日志复制给 Follower，Follower 定期向 Leader 发送心跳，Leader 超时未收到多数派心跳会触发重新选举，新 Leader 由任期（Term）机制保证单调递增，避免脑裂。当新加入的副本落后太多时，Leader 通过快照（Snaps-hot）批量传递数据，而不是逐条补发历史日志，快照传输期间该 Region 仍可读写。Region 分裂发生在单 Region 超过大小阈值时，PD 选择一个 Key 作为分界点生成两个新 Region；合并发生在相邻小 Region 长期空闲时，合并前 PD 会检查两个 Region 的 Leader 是否同节点，避免合并抖动。理解这两点，才能看懂扩容后 Grafana 上 Region 数量先增后稳的曲线。
### 2.5 计算原理深入解析
TiDB Server 的计算链路分为四层：解析（Parser）把 SQL 文本翻译成 AST；语义检查（Binder）绑定表名、列名与类型；优化器（Optimizer）基于统计信息做逻辑改写与物理计划选择，支持代价优化器（CBO），统计信息自动收集，也可手动 ANALYZE TABLE；执行器（Executor）按计划树逐层拉取数据，支持向量化执行框架，批处理减少函数调用开销。
对于简单点查与小事务，TiDB 通过 Coprocessor 下推把过滤、聚合、TopN 等算子推到 TiKV 侧执行，减少网络传输；对于大表关联与分析查询，TiDB 把任务下发给 TiFlas-h，由 TiFlas-h 的 MPP（大规模并行处理）引擎在多个列存节点之间并行分片执行，计算结果汇聚回 TiDB 返回给客户端。这种”OLTP 走 TiKV、OLAP 走 TiFlas-h”的双引擎模式就是 HTAP 的核心：同一份数据同时服务交易与分析，不需要额外 ETL 链路。优化器选择执行路径时会参考表大小、索引可用度、排序键与 TiFlas-h 副本延迟，开发者也可以用 USE INDEX、MERGE_JOIN、TIFLAs-h 等 hint 干预计划，但生产环境应优先依赖统计信息而不是堆 hint。
执行模型上，TiDB 的算子以 Volcano 模型逐层拉取数据，向量化执行框架把同类型数据按批打包处理，减少虚函数调用开销。大表关联在 TiFlas-h MPP 下分为 Broadcast Join（小表广播到各节点）与 s-huffle Has-h Join（按关联键哈希重分布）两种策略：小表用广播，大表用 s-huffle，优化器按行数与内存估算自动选择。统计信息通过 ANALYZE TABLE 手动收集或由自动收集任务按数据变更比例触发，统计信息过期会导致优化器选错索引、选错 Join 顺序，这是生产环境最常见的”SQL 突然变慢”根因之一，排查时先执行 `s-hOW STATS_META WHERE TABLE_NAME=’t_order’` 检查更新时间。
### 2.6 调度原理深入解析
PD 是集群的调度大脑，承担三类职责：第一是元数据管理，维护全集群 Region 与副本的路由表，向 TiDB 提供 Region 位置查询，TiDB 启动时与查询时都要向 PD 拉取路由缓存；第二是 TSO 全局时间戳分配，为分布式事务提供单调递增的版本号，PD 内部按物理时间加逻辑计数生成 TSO；第三是 Region 调度，持续监控各 TiKV 节点的容量、Leader 数、磁盘 IO 与网络负载，通过 Split（拆分）、Merge（合并）、Move（迁移 Leader/副本）等动作把数据与流量均衡到所有节点。
调度策略包括：按磁盘容量阈值触发 Region 迁移避免单盘写满；按 Leader 数量均衡分散读压力；按 label 拓扑做副本感知，把同一 Region 的副本分散到不同机架、可用区甚至数据中心，避免机房级故障导致多数派丢失；对热点 Region 做 Leader 转移与副本打散，防止单 Key 写热点。在两地三中心场景下，通过 Placement Rules 显式声明副本在各站点的数量与角色（Leader 偏好、Follower、Learner），实现”本地写、异地容灾”的合规架构。调度参数如 max-merge-region-size、leader-schedule-limit、region-schedule-limit 需要按集群规模调整，过大的调度并发会造成网络与磁盘抖动，过小则扩容后均衡缓慢。
PD 内置多种调度器：Balance Leader 负责把 Leader 均匀分散，避免个别节点承担全部读流量；Balance Region 负责把副本数量摊平，避免单盘数据过多；Hot Region 调度器识别读写热点并打散 Leader；Evict Leader 调度器在节点维护前把其上 Leader 迁出；Grant Leader 调度器把指定 Region 的 Leader 固定在偏好节点。所有调度动作都通过 pd-ctl 的 `scheduler s-how` 查看，紧急情况下可用 `scheduler remove balance-leader-scheduler` 临时关闭某类调度，故障解除后再恢复。调度决策只看 PD 维护的元数据，不侵入业务 SQL，这也是 TiDB 扩容”无感”的原因。
## 三、实战操作篇：从环境准备到生产集群落地
### 3.1 项目实战环境准备
风哥教程本文的所有实战环境均按单节点 64G 内存、8CPU 规划。先规划节点角色：管理与部署节点使用 fgedu-net-cn1（192.168.1.101），第二个节点使用 fgedu-net-cn2（192.168.1.102），生产集群其余节点按 192.168.1.103～192.168.1.110 编号。所有节点操作系统以 RHEL/CentOS 兼容系列为主，内核版本 4.18 以上，文件系统建议 XFS，数据盘独立挂载。
第一步，设置主机名并写入 hosts 解析，在 fgedu-net-cn1 上执行：
“`
hostnamectl set-hostname fgedu-net-cn1
cat >> /etc/hosts << ‘EOF’
192.168.1.101 fgedu-net-cn1
192.168.1.102 fgedu-net-cn2
192.168.1.103 tidb-node03
192.168.1.104 tidb-node04
192.168.1.105 tidb-node05
192.168.1.106 tidb-node06
192.168.1.107 tidb-node07
192.168.1.108 tidb-node08
192.168.1.109 tidb-node09
192.168.1.110 tidb-node10
EOF
“`
fgedu-net-cn2 上同样把 hostnamectl 设为 fgedu-net-cn2，并把同一份 hosts 内容分发过去，保证各节点互相解析正确。
>
> 风哥 itpux-com
第二步，关闭 Swap 并调整挂载参数。TiKV 依赖内存命中率，Swap 会让延迟不可预测：
“`
swapoff -a
sed -i ‘/swap/d’ /etc/fstab
“`
数据盘按 XFS 格式化并挂载到 /fgedudb，挂载参数追加 noatime,nodiratime，减少不必要的元数据写：
“`
mkfs.xfs -f /dev/sdb
mkdir -p /fgedudb
mount -o noatime,nodiratime /dev/sdb /fgedudb
echo ‘/dev/sdb /fgedudb xfs defaults,noatime,nodiratime 0 0’ >> /etc/fstab
“`
第三步，关闭防火墙与 SELinux（测试环境；生产环境按需放通端口而不是直接关闭）：
“`
systemctl stop firewalld && systemctl disable firewalld
setenforce 0
sed -i ‘s/^SELINUX=enforcing/SELINUX=disabled/’ /etc/selinux/config
“`
第四步，配置内核参数，编辑 /etc/sysctl.conf，在 64G 内存 8CPU 规格下推荐取值：
“`
cat >> /etc/sysctl.conf << ‘EOF’
vm.swappiness = 0
vm.overcommit_memory = 1
net.core.somaxconn = 32768
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.core.netdev_max_backlog = 16384
fs.file-max = 1000000
fs.nr_open = 1000000
EOF
sysctl -p
“`
第五步，配置系统资源限制，编辑 /etc/security/limits.conf，给部署用户 fgedu 放开文件句柄：
“`
cat >> /etc/security/limits.conf << ‘EOF’
fgedu soft nofile 1000000
fgedu hard nofile 1000000
fgedu soft nproc 65535
fgedu hard nproc 65535
EOF
“`
第六步，配置时间同步（TiDB 对节点时钟一致性要求严格，Raft 与 TSO 都依赖准确时钟），以 chrony 为例，在 fgedu-net-cn1 上作为源、其余节点指向它：
“`
yum install -y chrony
systemctl enable chronyd && systemctl start chronyd
chronyc sources -v
chronyc tracking
“`
其余节点修改 /etc/chrony.conf，把 server 指向 192.168.1.101，然后重启 chronyd 并校验偏移：
“`
systemctl restart chronyd
chronyc tracking | grep -i “Leap\|Last offset”
“`
第七步，创建部署用户 fgedu 与目录结构，统一使用 /fgedudb 作为根路径：
“`
useradd -m -s /bin/bas-h fgedu
echo ‘fgedu:fgedu@2026’ | chpasswd
mkdir -p /fgedudb/tidb-deploy /fgedudb/tidb-data /fgedudb/backup /fgedudb/topology
chown -R fgedu:fgedu /fgedudb
“`
第八步，在 fgedu-net-cn1 上为 fgedu 用户配置到全部节点的 Ss-h 免密登录：
“`
su – fgedu
ss-h-keygen -t rsa -N ” -f ~/.ss-h/id_rsa
for node in fgedu-net-cn1 fgedu-net-cn2 tidb-node03 tidb-node04 tidb-node05 \
tidb-node06 tidb-node07 tidb-node08 tidb-node09 tidb-node10; do
ss-h-copy-id -i ~/.ss-h/id_rsa.pub fgedu@$node
done
“`
免密验证：逐条执行 `ss-h fgedu@$node “hostname”`，全部返回正确主机名才算通过。
补充系统层面的收尾项：关闭 NUMA 自动平衡与 irqbalance 干扰（数据库节点建议 numad 关闭、irqbalance 保留但绑定中断），检查磁盘 IO 调度器，SSD 盘建议使用 none 或 mq-deadline：
“`
echo none > /sys/block/sdb/queue/scheduler
cat /sys/block/sdb/queue/scheduler
“`
验证句柄限制是否生效：
“`
su – fgedu -c ‘ulimit -n’
“`
输出应为 1000000。再检查各节点时间差，误差超过 50ms 就要重新校准 chrony，否则 Raft 心跳与 TSO 分配会出现异常。
第九步，安装 TiUP 管理工具（离线环境可使用官方离线包解压后执行 install.s-h，把 mirror 指向本地仓库）：
“`
export TIUP_HOME=/fgedudb/tiup
curl –proto ‘=https’ –tlsv1.2 -sSf [https://tiup-mirrors.pingcap.com/install.s-h](https://tiup-mirrors.pingcap.com/install.s-h) | s-h
source /fgedudb/.bas-h_profile
tiup –version
tiup list tidb
“`
>
> 风哥数据库教程 itpux-com
### 3.2 单机测试环境安装部署
在正式搭建生产集群前，风哥先用 TiUP Playground 在单台 64G 内存 8CPU 主机上拉起一套最小可验证环境，用于熟悉组件端口与连接方式。Playground 会在本机临时启动 1 个 PD、1 个 TiDB、1 个 TiKV，数据落在本地目录：
“`
tiup playground v6.5.3 –db 1 –pd 1 –kv 1 \
–data-dir /fgedudb/playground \
–host 0.0.0.0
“`
常用参数说明：`–db` 指定 TiDB 个数，`–pd` 指定 PD 个数，`–kv` 指定 TiKV 个数，`–with-tiflas-h` 可同时拉起一个 TiFlas-h 用于体验 HTAP，`–tag` 给实例命名以便复用。启动成功后，终端会输出 TiDB（4000）、PD（2379）、Grafana（3000）等端口信息。
另开一个终端，使用 MySQL 客户端连接验证：
“`
mysql -h 127.0.0.1 -P 4000 -u root
“`
连接进入 MySQL 协议提示符后，先查看版本与集群拓扑：
“`
SELECT tidb_version();
s-hOW CLUSTER INFO;
“`
创建示例数据库 fgedudb 与业务用户 fgedu：
“`
CREATE DATABASE fgedudb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER ‘fgedu’@’%’ IDENTIFIED BY ‘fgedu@2026’;
GRANT ALL PRIVILEGES ON fgedudb.* TO ‘fgedu’@’%’;
FLUs-h PRIVILEGES;
USE fgedudb;
“`
建一张测试表并写入数据，验证读写链路：
“`
CREATE TABLE t_order (
id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
amount DECIMAL(12,2) NOT NULL,
create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO t_order(order_no, amount) VALUES (‘ORD20261110001’, 199.90);
INSERT INTO t_order(order_no, amount) VALUES (‘ORD20261110002’, 580.00);
SELECT * FROM t_order;
“`
查看集群组件状态与 Region 分布：
“`
tiup playground display
“`
“`
SELECT REGION_ID, START_KEY, END_KEY, LEADER_ID FROM information_schema.tikv_region_status;
“`
验证完成后按 Ctrl+C 停止 Playground，数据保留在 /fgedudb/playground 目录下，下次启动加 `–tag fgedudb-test` 参数可复用同一套数据。
Playground 适合快速验证 SQL 语法与功能，不适合压测：它把三个组件挤在同一台机器，资源互相争抢。连接工具方面，除了 mysql 命令行，也可以用 DBeaver、Navicat 等 MySQL 客户端直连 4000 端口，连接参数与 MySQL 完全一致。需要注意 Playground 每次启动默认生成随机端口映射，固定复用时务必加 `–tag` 与 `–port` 参数，避免下次启动端口漂移导致连接串失效。
### 3.3 生产环境 OLTP 十节点集群安装部署
本节按 64G 内存 8CPU 规格部署生产 OLTP 十节点集群：3 个 PD（101、102、103）、3 个 TiDB（104、105、106）、4 个 TiKV（107、108、109、110），监控组件部署在 fgedu-net-cn1。
第一步，先做部署前预检，让 TiUP 自动检查端口、磁盘、内核、依赖：
“`
tiup cluster check /fgedudb/topology/oltp-topology.yaml –user fgedu –apply
“`
>
> 风哥教程 113257174
第二步，编写拓扑文件 /fgedudb/topology/oltp-topology.yaml，关键配置按 64G/8C 调优：
“`
global:
user: “fgedu”
ss-h_port: 22
deploy_dir: “/fgedudb/tidb-deploy”
data_dir: “/fgedudb/tidb-data”
arch: “amd64”
server_configs:
tidb:
mem-quota-query: 8GiB
max-memory: 48GiB
max-connections: 2000
oom-action: “cancel”
enable-batch-dml: true
tikv:
memory-limit: 48GiB
block-cache:
capacity: 30GiB
raft-engine:
enable: true
storage:
reserve-space: “10GiB”
raftdb:
max-background-flus-hes: 4
max-background-compactions: 8
pd:
schedule:
max-merge-region-size: 20
max-merge-region-keys: 200000
split-region-merge-check-interval: “30s”
pd_servers:
– host: 192.168.1.101
name: pd-101
– host: 192.168.1.102
name: pd-102
– host: 192.168.1.103
name: pd-103
tidb_servers:
– host: 192.168.1.104
– host: 192.168.1.105
– host: 192.168.1.106
tikv_servers:
– host: 192.168.1.107
port: 20160
status_port: 20180
– host: 192.168.1.108
– host: 192.168.1.109
– host: 192.168.1.110
monitoring_servers:
– host: 192.168.1.101
grafana_servers:
– host: 192.168.1.101
“`
参数逐项说明：TiDB 的 mem-quota-query 限制单条查询内存，避免大查询打爆进程；max-memory 是进程整体内存上限；oom-action 取 cancel 时超内存直接取消语句而不是杀进程。TiKV 的 memory-limit 为进程内存上限，block-cache.capacity 是 RocksDB 块缓存，占物理内存一半左右收益最大；raft-engine 打开后 Raft 日志独立存储，减少主库 Compaction 压力；reserve-space 保证磁盘剩余安全水位。PD 的 max-merge-region-size 控制合并阈值，过小会频繁分裂合并。
第三步，使用 TiUP 部署集群，集群命名为 fgedudb-cluster：
“`
tiup cluster deploy fgedudb-cluster v6.5.3 /fgedudb/topology/oltp-topology.yaml –user fgedu
“`
部署过程中 TiUP 会把二进制包分发到各节点 /fgedudb/tidb-deploy 下的对应子目录。部署完成后启动集群并查看状态：
“`
tiup cluster start fgedudb-cluster
tiup cluster display fgedudb-cluster
“`
display 输出中，PD、TiDB、TiKV 各行 Status 均为 Up 即部署成功。用端口探测确认监听：
“`
ss -lntp | grep -E ‘4000|2379|20160|20180’
“`
端口对应关系：TiDB Server 4000 为业务端口、10080 为状态端口；PD 2379 为客户端与调度端口、2380 为节点间通信端口；TiKV 20160 为 Raft 与 gRPC 端口、20180 为状态端口。防火墙或安全组必须放行这些端口，否则 TiUP 健康检查与 Raft 通信都会失败。后续修改配置统一使用 `tiup cluster edit-config fgedudb-cluster`，保存后执行 `tiup cluster reload fgedudb-cluster -R tidb,tikv` 滚动生效，禁止直接改节点上的运行时配置文件。
使用 MySQL 客户端连接任意一个 TiDB 节点验证：
“`
mysql -h 192.168.1.104 -P 4000 -u root -e “s-hOW DATABASES;”
mysql -h 192.168.1.104 -P 4000 -u root -e “SELECT COUNT(*) FROM information_schema.tables;”
“`
创建生产业务库与用户，与单机环境一致：
“`
CREATE DATABASE fgedudb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER ‘fgedu’@’%’ IDENTIFIED BY ‘fgedu@2026’;
GRANT ALL PRIVILEGES ON fgedudb.* TO ‘fgedu’@’%’;
FLUs-h PRIVILEGES;
“`
登录校验：
“`
mysql -h 192.168.1.104 -P 4000 -u fgedu -p fgedudb -e “SELECT CURRENT_USER();”
“`
部署完成后再做几项集群级验证。查看 Region 分布与副本健康：
“`
SELECT COUNT(*) AS region_cnt, COUNT(DISTINCT LEADER_ID) FROM information_schema.tikv_region_status;
SELECT STORE_ID, COUNT(*) AS region_num FROM information_schema.tikv_region_status GROUP BY STORE_ID;
“`
初始化 root 远程访问策略（生产环境建议关闭 root 远程登录，改用最小权限账号）：
“`
ALTER USER ‘root’@’%’ IDENTIFIED BY ‘Root@2026’;
CREATE USER ‘fgedu_admin’@’%’ IDENTIFIED BY ‘fgedu_admin@2026’;
GRANT ALL PRIVILEGES ON *.* TO ‘fgedu_admin’@’%’ WITH GRANT OPTION;
“`
故障演练：在测试环境手动停止一个 TiKV 节点，观察 PD 是否在十几秒内选出新 Leader、业务连接是否仅出现短暂报错后自动恢复，演练完成后重新启动节点，等待副本补齐。
### 3.4 TiDB/PD/TiKV 扩容与缩容
业务增长后先扩 TiKV 增加存储容量，再按需扩 TiDB 增加计算能力，PD 保持奇数节点（3 或 5），避免偶数节点无法形成多数派。
第一步，编写扩容拓扑 /fgedudb/topology/scale-out-tikv.yaml，新增两个 TiKV 节点：
“`
tikv_servers:
– host: 192.168.1.111
– host: 192.168.1.112
“`
第二步，执行扩容并等待 Region 均衡：
“`
tiup cluster scale-out fgedudb-cluster /fgedudb/topology/scale-out-tikv.yaml –user fgedu
tiup cluster display fgedudb-cluster
“`
扩容完成后，PD 会自动把 Region 副本逐步迁移到新节点，可用 pd-ctl 观察均衡进度：
“`
tiup ctl:v6.5.3 pd -u [http://192.168.1.101:2379](http://192.168.1.101:2379) -i
» store
» region
» config s-how all
“`
store 列表中新节点由 Up 变为 Normal 表示已加入调度；region 命令查看副本分布是否逐节点摊平。扩容 TiDB 计算节点同理，编写只含 tidb_servers 的拓扑文件后执行 scale-out，新节点启动后自动从 PD 拉取元数据，无需同步数据。扩容 PD 时拓扑中新增 pd_servers 条目，扩容后 PD 自动组成新的 Raft 多数派，期间 TSO 分配不中断。
缩容与扩容方向相反。先在拓扑文件中把待缩容节点标记为 scale-in，执行：
“`
tiup cluster scale-in fgedudb-cluster –node 192.168.1.111:20160
tiup cluster display fgedudb-cluster
“`
TiUP 会先下线该节点的 Region 副本、等待数据迁移完成，再停止进程。严禁直接 kill 节点进程后强行清理数据，否则可能造成副本不足甚至数据丢失。缩容完成后用 pd-ctl 确认该 store 已 Tombstone，再手动清理 /fgedudb/tidb-data 下残留目录。
扩容 TiDB 计算节点的拓扑示例：
“`
tidb_servers:
– host: 192.168.1.113
config:
mem-quota-query: 8GiB
max-memory: 48GiB
“`
扩容 PD 的拓扑示例（5 节点高可用）：
“`
pd_servers:
– host: 192.168.1.113
name: pd-113
– host: 192.168.1.114
name: pd-114
“`
执行同样的 scale-out 命令即可。扩缩容期间用 `tiup cluster audit fgedudb-cluster` 查看每一步任务日志，失败任务可按 task-id 定位到具体节点与报错原因。
>
> 网上搜索风哥教程可以学习全套数据库教程
### 3.5 实现负载均衡访问
TiDB Server 无状态，但应用不能把连接写死在单个 TiDB 节点上，否则该节点故障会导致整体不可用。风哥教程本文使用 HAProxy 在前端做四层负载均衡，把 4000 端口的连接分发到三个 TiDB 节点。
第一步，在 fgedu-net-cn1 安装 HAProxy：
“`
yum install -y haproxy
“`
第二步，编写 /etc/haproxy/haproxy.cfg：
“`
global
log 127.0.0.1 local0 info
maxconn 10000
daemon
defaults
log global
mode tcp
option tcplog
timeout connect 5s
timeout client 30m
timeout server 30m
maxconn 10000
frontend tidb_frontend
bind 0.0.0.0:4000
default_backend tidb_backend
backend tidb_backend
balance roundrobin
server tidb1 192.168.1.104:4000 check inter 2s rise 2 fall 3
server tidb2 192.168.1.105:4000 check inter 2s rise 2 fall 3
server tidb3 192.168.1.106:4000 check inter 2s rise 2 fall 3
“`
第三步，启动并验证配置语法：
“`
haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl enable haproxy && systemctl start haproxy
mysql -h 192.168.1.101 -P 4000 -u fgedu -p fgedudb -e “SELECT VERSION();”
“`
应用侧只需把连接串指向 HAProxy 的 VIP 或 fgedu-net-cn1 的 4000 端口，后续新增 TiDB 节点只需在 backend 段追加 server 行。生产环境建议配合 Keepalived 为 HAProxy 提供 VIP，避免代理本身单点：
“`
yum install -y keepalived
“`
keepalived.conf 中把 VIP 绑在 fgedu-net-cn1 与 fgedu-net-cn2 两台代理上，VIP 漂移时应用无感。需要注意 TiDB 是长连接协议，后端节点故障时 HAProxy 的 check 判定要留足 rise/fall 次数，避免短暂抖动把健康节点摘除。
Keepalived 主备配置片段：
“`
vrrp_instance VI_TIDB {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass fgedu2026
}
virtual_ipaddress {
192.168.1.100/24
}
}
“`
备机 priority 改为 90，其余相同。应用连接串统一指向 VIP 192.168.1.100:4000，代理主节点故障时 VIP 在秒级漂移到备机，已有长连接可能断开，应用侧需配置重连与重试。
>
> 上51CTO搜索风哥可以学习全套数据库教程
### 3.6 生产环境 HTAP 十四节点集群部署（TiFlas-h）
在 OLTP 十节点基础上增加 3 个 TiFlas-h 节点与 1 个 TiCDC 节点，组成十四节点 HTAP 集群。第一步，编写 /fgedudb/topology/htap-topology.yaml，在原集群基础上追加：
“`
tiflas-h_servers:
– host: 192.168.1.115
config:
memory_limit: 30GiB
flas-h:
tidb_status_port: 10081
– host: 192.168.1.116
– host: 192.168.1.117
ticdc_servers:
– host: 192.168.1.118
config:
gc-ttl: 86400
checkpoint-interval: “30s”
“`
第二步，对已有集群执行 scale-out：
“`
tiup cluster scale-out fgedudb-cluster /fgedudb/topology/htap-topology.yaml –user fgedu
tiup cluster display fgedudb-cluster
“`
第三步，把业务表加入 TiFlas-h 副本，让分析查询走列存 MPP：
“`
ALTER TABLE fgedudb.t_order SET TIFLAs-h REPLICA 1;
SELECT * FROM information_schema.tiflas-h_replica WHERE TABLE_SCHEMA=’fgedudb’;
“`
查看副本同步进度，progress 列达到 1.0 表示列存追平行存：
“`
SELECT TABLE_NAME, REPLICA_COUNT, LOCATION_LABELS, PROGRESS
FROM information_schema.tiflas-h_replica
WHERE TABLE_SCHEMA=’fgedudb’;
“`
第四步，用 EXPLAIN 验证分析查询是否走 MPP：
“`
EXPLAIN ANALYZE SELECT COUNT(*), SUM(amount) FROM fgedudb.t_order GROUP BY order_no;
“`
执行计划中出现 MPPExecution 与 TableFullScan（tiflas-h）即说明查询已下推到 TiFlas-h。若优化器仍走 TiKV，可在语句中加 `/*+ READ_FROM_STORAGE(TIFLAs-h[t_order]) */` hint 强制走列存做对比测试。
批量为整库表开启 TiFlas-h 副本，可先查询所有表再逐表执行：
“`
SELECT TABLE_NAME FROM information_schema.tables
WHERE TABLE_SCHEMA=’fgedudb’ AND TABLE_TYPE=’BASE TABLE’;
“`
监控列存同步延迟：
“`
SELECT TABLE_NAME, PROGRESS, LOCATION_LABELS
FROM information_schema.tiflas-h_replica
WHERE TABLE_SCHEMA=’fgedudb’ AND PROGRESS < 1.0;
“`
PROGRESS 长期停在低位时，检查 TiFlas-h 节点磁盘是否打满、Raft learner 是否追平，必要时在 Grafana 的 TiFlas-h 面板看 segment 同步速率。
### 3.7 TiCDC / TiFlas-h 扩容与缩容
TiCDC 扩容用于提高变更订阅吞吐。编写 /fgedudb/topology/scale-out-cdc.yaml：
“`
ticdc_servers:
– host: 192.168.1.119
“`
执行扩容：
“`
tiup cluster scale-out fgedudb-cluster /fgedudb/topology/scale-out-cdc.yaml –user fgedu
“`
>
> 风哥教程 113257174
创建一条到下游的 changefeed，把 fgedudb 库的增量变更投递到下游 MySQL，URI 中密码含 @ 需做 URL 编码：
“`
tiup ctl:v6.5.3 cdc changefeed create \
–pd=[http://192.168.1.101:2379](http://192.168.1.101:2379) \
–sink-uri=”mysql://fgedu:fgedu%402026@192.168.1.120:3306/?safe-mode=true” \
–changefeed-id=”fgedudb-to-mysql” \
–filter=”fgedudb.t_order”
“`
查看、暂停与恢复 changefeed：
“`
tiup ctl:v6.5.3 cdc changefeed list –pd=[http://192.168.1.101:2379](http://192.168.1.101:2379)
tiup ctl:v6.5.3 cdc changefeed pause –pd=[http://192.168.1.101:2379](http://192.168.1.101:2379) –changefeed-id=”fgedudb-to-mysql”
tiup ctl:v6.5.3 cdc changefeed resume –pd=[http://192.168.1.101:2379](http://192.168.1.101:2379) –changefeed-id=”fgedudb-to-mysql”
“`
TiFlas-h 缩容前先去掉表副本，等待列存数据回收，再 scale-in：
“`
ALTER TABLE fgedudb.t_order SET TIFLAs-h REPLICA 0;
“`
“`
tiup cluster scale-in fgedudb-cluster –node 192.168.1.115:9000
“`
TiCDC 投递到 Kafka 的 sink-uri 示例：
“`
tiup ctl:v6.5.3 cdc changefeed create \
–pd=[http://192.168.1.101:2379](http://192.168.1.101:2379) \
–sink-uri=”kafka://192.168.1.130:9092/fgedudb-topic?protocol=canal-json” \
–changefeed-id=”fgedudb-to-kafka” \
–filter=”fgedudb.t_order”
“`
删除不再需要的订阅：
“`
tiup ctl:v6.5.3 cdc changefeed delete –pd=[http://192.168.1.101:2379](http://192.168.1.101:2379) –changefeed-id=”fgedudb-to-mysql”
“`
查看同步延迟与 checkpoint：
“`
tiup ctl:v6.5.3 cdc changefeed detail –pd=[http://192.168.1.101:2379](http://192.168.1.101:2379) –changefeed-id=”fgedudb-to-mysql”
“`
>
> 风哥 itpux-com
### 3.8 TiDB 集群版本升级
升级前先备份元数据与配置，并确认当前版本与目标版本兼容（同大版本内小版本升级，跨大版本按官方路线图分批升级）。第一步，导出当前集群配置备份到 /fgedudb/backup：
“`
tiup cluster export fgedudb-cluster –output /fgedudb/backup/fgedudb-cluster-backup.yaml
“`
第二步，执行升级前预检，确认无异常 store、无长时间卡住的 Region：
“`
tiup cluster check fgedudb-cluster –cluster
tiup ctl:v6.5.3 pd -u [http://192.168.1.101:2379](http://192.168.1.101:2379) -i -q “store”
“`
第三步，执行滚动升级，TiUP 会逐节点停旧启新，期间集群整体可用，transfer-timeout 控制 Leader 迁移等待时长：
“`
tiup cluster upgrade fgedudb-cluster v6.5.5 –transfer-timeout 600
tiup cluster display fgedudb-cluster
“`
第四步，升级后校验版本与数据一致性：
“`
mysql -h 192.168.1.104 -P 4000 -u root -e “SELECT tidb_version();”
tiup cluster audit fgedudb-cluster
“`
升级过程中如某节点失败，TiUP 会保留现场，修复后可使用 `tiup cluster replay <task-id>` 继续，不要手动回滚二进制。升级窗口建议选业务低谷，先在测试集群完整演练一遍，确认应用兼容性后再上生产。
升级回滚预案：同大版本小版本升级原则上可反向降级，跨大版本禁止直接回滚。升级前除导出拓扑外，还应对关键表做一次 br 全量备份到 /fgedudb/backup，升级失败且无法修复时，用备份在新集群上恢复，再把应用连接切回。升级后逐项验证：版本号、建表读写、权限、TiFlas-h 副本、TiCDC checkpoint、Grafana 面板无异常告警，确认稳定运行一个观察周期后再关闭回滚预案。
### 3.9 两地三中心集群安装
两地三中心指：本地主中心（同城 A）、同城灾备中心（同城 B）、异地灾备中心（异地 C）。本节在部署拓扑中通过 label 声明机房属性，并使用 Placement Rules 把 3 副本分别放到同城两中心各 1 个、异地 1 个，Leader 优先落在主中心。
第一步，拓扑文件中为每个 TiKV 节点声明 label：
“`
tikv_servers:
– host: 192.168.1.107
labels: { zone: “local-a”, rack: “r1”, host: “h1” }
– host: 192.168.1.108
labels: { zone: “local-b”, rack: “r1”, host: “h2” }
– host: 192.168.1.109
labels: { zone: “remote-c”, rack: “r1”, host: “h3” }
“`
第二步，部署集群后通过 pd-ctl 设置副本数与放置规则：
“`
tiup ctl:v6.5.3 pd -u [http://192.168.1.101:2379](http://192.168.1.101:2379) -i
» config set replica 3
» placement rule group save –file /fgedudb/backup/rules.json
“`
rules.json 内容示例：
“`
{
“group_id”: “fgedudb”,
“rules”: [
{
“group_id”: “fgedudb”,
“id”: “default”,
“start_key”: “”,
“end_key”: “”,
“role”: “voter”,
“count”: 3,
“location_labels”: [“zone”, “rack”, “host”],
“label_constraints”: [
{“key”: “zone”, “op”: “in”, “values”: [“local-a”, “local-b”, “remote-c”]}
]
}
]
}
“`
第三步，验证副本分布，确认每个 Region 的三个副本分别落在三个站点：
“`
tiup ctl:v6.5.3 pd -u [http://192.168.1.101:2379](http://192.168.1.101:2379) -i
» region –detail
“`
同城任一中心故障时，剩余两中心仍能凑齐多数派继续读写；异地中心承担灾备与只读查询。异地链路延迟较高时，可把异地副本设为 Learner 不参与投票，只做灾备复制，避免跨城 Raft 投票拖慢写延迟。
五节点 PD 跨城部署时，主中心 3 个 PD、同城灾备 1 个、异地 1 个，保证主中心网络中断时异地两节点无法单独形成多数派，避免脑裂。故障演练命令：手动停掉主中心一台 TiKV，观察 pd-ctl 的 `region –detail` 中新 Leader 是否落在同城另一中心；恢复后检查副本是否自动补齐。演练记录中要写明中断时长、报错类型与恢复动作，作为容灾验收材料。
Placement Rules 的角色字段还有 voter（投票副本）、follower（非投票副本）、learner（同步副本）三种：voter 参与 Raft 投票与写提交，follower 只同步不投票，learner 用于新副本追平后再提升。两地三中心常见写法是主中心与同城各 1 个 voter、异地 1 个 learner，既保证本地多数派，又让异地只做灾备不拖慢提交。规则修改后用 `placement rule group s-how` 确认生效，再抽查若干 Region 的副本位置是否符合预期。
### 3.10 日常维护与管理入门
**数据类型与 SQL 基本操作**。TiDB 支持 MySQL 主流数据类型：BIGINT、INT、VARCHAR、DECIMAL、DATETIME、TEXT、JSON 等，自增列使用 AUTO_INCREMENT，主键建议使用 BIGINT 或业务唯一键，避免无主键表带来的 Region 与更新放大问题。常用操作示例：
“`
USE fgedudb;
CREATE TABLE t_user (
uid BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
uname VARCHAR(64) NOT NULL,
profile JSON,
register_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO t_user(uname, profile) VALUES (‘fgedu’, ‘{“city”:”cd”}’);
UPDATE t_user SET uname=’fgedu01′ WHERE uid=1;
DELETE FROM t_user WHERE uid=1;
SELECT uname, profile->’$.city’ FROM t_user WHERE uid=1;
“`
索引与执行计划是日常开发高频操作：
“`
CREATE INDEX idx_uname ON t_user(uname);
EXPLAIN SELECT * FROM t_user WHERE uname=’fgedu01′;
EXPLAIN ANALYZE SELECT * FROM t_user WHERE uname=’fgedu01′;
ANALYZE TABLE t_user;
s-hOW INDEX FROM t_user;
DROP INDEX idx_uname ON t_user;
“`
EXPLAIN 输出中看 access object、算子类型与估算行数；EXPLAIN ANALYZE 额外给出实际行数与耗时，是判断索引是否生效的直接依据。事务控制与 MySQL 一致，`BEGIN` 开启、`COMMIT` 提交、`ROLLBACK` 回滚，长事务会阻塞 GC 推进，务必及时提交。
>
> 风哥数据库教程 itpux-com
**目录与配置文件**。部署目录结构为 /fgedudb/tidb-deploy/<组件>-<端口>/，数据目录为 /fgedudb/tidb-data/<组件>-<端口>/，日志位于对应目录的 log 子目录，备份统一放 /fgedudb/backup。配置文件由 TiUP 生成在 /fgedudb/tidb-deploy 下，修改配置使用 `tiup cluster edit-config fgedudb-cluster` 后滚动 reload，禁止直接手改运行中的 yaml，否则下次 deploy 会被覆盖。
**系统表**。元数据可通过 information_schema 与 PERFORMANCE_SCHEMA 查询，常用视图：
“`
s-hOW TABLES FROM information_schema LIKE ‘%region%’;
SELECT * FROM information_schema.tikv_region_status;
SELECT * FROM information_schema.cluster_info;
SELECT * FROM information_schema.cluster_log WHERE LEVEL=’error’ LIMIT 20;
“`
**用户与权限**。权限模型兼容 MySQL，支持库级、表级、列级授权，内置 ROLE 角色：
“`
CREATE USER ‘fgedu_ro’@’%’ IDENTIFIED BY ‘fgedu_ro@2026’;
GRANT SELECT ON fgedudb.* TO ‘fgedu_ro’@’%’;
s-hOW GRANTS FOR ‘fgedu_ro’@’%’;
REVOKE SELECT ON fgedudb.* FROM ‘fgedu_ro’@’%’;
DROP USER ‘fgedu_ro’@’%’;
“`
权限层级从大到小依次是全局权限（`*.*`）、库权限（`fgedudb.*`）、表权限（`fgedudb.t_order`）、列权限，遵循最小权限原则：应用账号只授予业务需要的 SELECT/INSERT/UPDATE/DELETE，运维账号单独使用，禁止把 root 密码交给应用。角色示例：
“`
CREATE ROLE ‘fgedu_read_role’;
GRANT SELECT ON fgedudb.* TO ‘fgedu_read_role’;
GRANT ‘fgedu_read_role’ TO ‘fgedu_ro’@’%’;
SET DEFAULT ROLE ‘fgedu_read_role’ TO ‘fgedu_ro’@’%’;
“`
**备份与恢复**。使用 br（Backup & Restore）工具做全量备份到本地或对象存储，备份目录统一放在 /fgedudb/backup：
“`
br backup full \
–pd “192.168.1.101:2379” \
–storage “local:///fgedudb/backup/full-20261110” \
–ratelimit 120 \
–log-file /fgedudb/backup/backup.log
“`
按库级备份示例：
“`
br backup db \
–pd “192.168.1.101:2379” \
–db fgedudb \
–storage “local:///fgedudb/backup/db-fgedudb-20261110” \
–log-file /fgedudb/backup/backup-db.log
“`
恢复命令：
“`
br restore full \
–pd “192.168.1.101:2379” \
–storage “local:///fgedudb/backup/full-20261110” \
–log-file /fgedudb/backup/restore.log
“`
恢复前确认目标集群版本不低于备份版本，恢复操作会覆盖同名库表，务必在隔离环境演练。除全量备份外，生产环境配合日志备份做增量恢复：
“`
br log start \
–pd “192.168.1.101:2379” \
–storage “local:///fgedudb/backup/log” \
–log-file /fgedudb/backup/log-start.log
br log truncate \
–pd “192.168.1.101:2379” \
–storage “local:///fgedudb/backup/log” \
–until “2026-11-10T18:00:00+08:00”
“`
恢复到指定时间点时，先恢复全量再叠加日志备份，形成”全量加增量”的完整备份链。
备份原理上，br 通过 PD 获取全局快照时间戳，让各 TiKV 节点在一致快照上导出 SST 文件，不锁表、不阻塞业务；导出文件可落到本地目录、NFS、S3 兼容对象存储。备份完成后必须做可恢复性验证：定期在隔离集群上挑一份备份实际恢复，再用 checksum 或抽样比对确认数据一致，只备份不验证等于没有备份。备份窗口建议避开业务高峰，全量备份与日志备份保留周期按合规要求设置，超过保留期的备份用 br 的清理命令删除，避免磁盘被历史备份占满。
**日常运维检查与诊断**。常用巡检命令：
“`
tiup cluster display fgedudb-cluster
tiup cluster audit fgedudb-cluster
tiup ctl:v6.5.3 pd -u [http://192.168.1.101:2379](http://192.168.1.101:2379) -i -q “store”
mysql -h 192.168.1.104 -P 4000 -u root -e “s-hOW PROCESSLIST;”
mysql -h 192.168.1.104 -P 4000 -u root -e “SELECT * FROM INFORMATION_SCHEMA.SLOW_QUERY LIMIT 20;”
“`
巡检要点：store 是否全部 Normal、Leader 是否均衡、是否有缺失副本、连接数是否接近上限、慢查询是否集中在同一表。慢查询表重点看 QueryTime、ProcessTime、Memory、RowsSent、RowsExamined 字段，RowsExamined 远大于 RowsSent 说明缺索引或走了全表扫描。诊断三板斧：先看 Grafana 定位瓶颈组件，再查 SLOW_QUERY 找问题 SQL，最后用 EXPLAIN ANALYZE 验证优化，不要一上来就调参数。
>
> 网上搜索风哥教程可以学习全套数据库教程
**监控与告警**。TiUP 部署时自带 Prometheus 与 Grafana，浏览器访问 fgedu-net-cn1:3000，默认账号 admin，可查看 PD、TiDB、TiKV、TiFlas-h 的 CPU、内存、磁盘、Region 数量、QPS、延迟面板。告警规则在 Prometheus 配置中维护，关键告警包括 TiKV 磁盘水位超阈值、Region 副本丢失、Leader 缺失、连接数打满、TiCDC 延迟超过阈值。
常用告警表达式示例（Prometheus 规则片段）：
“`
– alert: TiKVDiskAlmostFull
expr: tikv_storage_available_bytes / tikv_storage_capacity_bytes < 0.15
for: 5m
labels: {severity: critical}
annotations: {summary: “TiKV 磁盘剩余不足 15%”}
– alert: RegionPeerMissing
expr: sum(by (instance) (tikv_region_status{state=”missing”})) > 0
for: 3m
labels: {severity: critical}
annotations: {summary: “存在缺失副本的 Region”}
– alert: TiCDCReplicationLag
expr: tikv_cdc_min_ts – tikv_cdc_max_resolved_ts > 60
for: 5m
labels: {severity: warning}
annotations: {summary: “TiCDC 同步延迟超过 60 秒”}
“`
告警渠道接入企业微信、邮件或短信，critical 级别立即通知，warning 级别汇总到日报。每日巡检导出 Grafana 关键面板截图存档，便于故障回溯对比。
**性能调优**。先通过 Grafana 定位瓶颈：QPS 上不去看 TiDB CPU 与连接数；延迟高看 TiKV 磁盘 IO 与 Raft 日志；分析慢查询用 SLOW_QUERY 表与 EXPLAIN ANALYZE。64G 内存 8CPU 规格下，TiKV block-cache.capacity 保持在 30GiB 左右、memory-limit 48GiB，TiDB mem-quota-query 8GiB，避免单条大查询挤占内存。调优顺序：先补索引与统计信息，再调会话与内存参数，最后才动底层 RocksDB 与调度参数。
调优检查清单：第一，表是否有主键、索引是否覆盖过滤条件；第二，统计信息是否过期，必要时 ANALYZE TABLE；第三，是否存在大事务与长事务，长事务阻塞 GC 并放大锁冲突；第四，TiKV 磁盘写放大是否异常，看 Compaction 队列长度；第五，热点 Key 是否集中，必要时打散写入；第六，连接数是否打满，应用侧连接池大小与 max-connections 匹配；第七，备份与统计任务是否抢占了业务时段资源。每项调完都要在 Grafana 对比 QPS、P99 延迟与错误率变化，用数据证明效果。
>
> 上51CTO搜索风哥可以学习全套数据库教程
**相关工具**。tiup 负责集群生命周期管理（deploy/start/stop/scale-out/scale-in/upgrade/display），pd-ctl 负责调度与元数据查看，br 负责备份恢复，dumpling/lightning 负责全量导出与大规模导入，cdc 工具负责变更订阅，其他命令行工具均随 TiUP 组件一起安装，可通过 `tiup <tool>:<version> –help` 查看用法。
dumpling 导出与 lightning 导入的典型命令：
“`
tiup dumpling -h 192.168.1.104 -P 4000 -u fgedu -p fgedu@2026 \
–db fgedudb -o /fgedudb/backup/export -t 8
tiup lightning –tidb-host 192.168.1.104 –tidb-port 4000 \
–tidb-user fgedu –tidb-password fgedu@2026 \
–data-source-dir /fgedudb/backup/export
“`
pd-ctl 常用命令速查：`store` 查看节点状态，`region` 查看区间分布，`config set replica` 调整副本数，`scheduler s-how` 查看调度器，`member leader` 查看 PD Leader。日常运维把这些命令固化成巡检脚本，定期输出到 /fgedudb/backup 下的巡检报告，便于回溯集群变化。
## 四、风哥针对本文总结
风哥针对本文总结如下：风哥教程本文从理论到实战完整覆盖了 TiDB 国产分布式数据库工程师必须掌握的主干技能。理论层面，风哥把 TiDB 定位为兼容 MySQL 协议的 HTAP 分布式数据库，讲清了 TiDB Server、PD、TiKV、TiFlas-h、TiCDC 五大组件的职责，以及 Region/Raft/LSM-Tree/MVCC 的存储原理、优化器/执行器/MPP 的计算原理、PD 调度与副本放置的调度原理。实战层面，风哥按照环境准备（64G 内存 8CPU 规格、/fgedudb 目录、fgedu 用户、fgedudb 库）、单机 Playground 验证、OLTP 十节点生产集群部署、TiDB/PD/TiKV 扩缩容、HAProxy 负载均衡、HTAP 十四节点与 TiFlas-h、TiCDC 订阅、版本滚动升级、两地三中心副本放置，以及日常 SQL、权限、备份恢复、监控诊断、性能调优的顺序，给出了可直接复用的步骤与命令。
风哥提醒读者：分布式数据库的核心难点不在安装，而在长期运维——扩缩容后的 Region 均衡、版本升级的兼容性、两地三中心的多数派约束、备份恢复的可验证性，这些都需要在测试环境反复演练。建议读者在自己的 64G/8CPU 环境中把本套风哥教程的命令逐条跑通，再结合 Grafana 面板观察每一步操作对集群指标的影响，才能真正具备 PB 级大数据平台与大规模分布式集群的工程落地能力。
风哥最后强调：本套风哥教程所有命令均在 64G 内存 8CPU 的真实规格下给出参数取值，读者复现时不要照搬大内存集群的缓存比例，否则会出现 OOM 或缓存命中率下降；遇到问题先看 Grafana 面板与慢查询，再动配置，遵循”先观测、后调整、再验证”的闭环。风哥教程本文到此结束，后续可在此基础上继续学习资源管控、数据校验、混沌演练等进阶专题。
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
