1 TiDB介绍
1.1 [1]定义
01.介绍
a.概念
TiDB 是 PingCAP 公司自主设计研发的开源分布式关系型数据库
它是一款同时支持在线事务处理与在线分析处理（HTAP）的融合型分布式数据库产品
TiDB 兼容 MySQL 5.7 协议和 MySQL 生态工具，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库等核心特性
目标是为用户提供一站式 OLTP（Online Transactional Processing）、OLAP（Online Analytical Processing）、HTAP 解决方案
---------------------------------------------------------------------------------------------------------
TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景
其设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景
TiDB 对业务没有任何侵入性，能优雅地替换传统的数据库中间件、数据库分库分表等 Sharding 方案
同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大地提升研发的生产力
---------------------------------------------------------------------------------------------------------
TiDB 的名称来源于 Ti 代表 Titanium（钛），寓意强度和可靠性
DB 代表 Database（数据库）
TiDB 项目始于 2015 年，2016 年开源，2017 年发布 1.0 GA 版本
目前已经在全球范围内被数千家企业用户采用，涵盖金融、电商、物流、游戏、互联网等多个行业
b.核心定位
分布式关系型数据库：TiDB 是一个真正的分布式数据库，数据分散存储在多个节点上，通过 Raft 协议保证数据一致性
MySQL 兼容：高度兼容 MySQL 5.7 协议，大多数情况下可以直接替换 MySQL 而无需修改代码
HTAP 融合：同时支持 OLTP 和 OLAP 场景，一套系统解决事务处理和实时分析需求
云原生架构：采用存储和计算分离的架构，支持在云环境中弹性伸缩
---------------------------------------------------------------------------------------------------------
水平扩展：通过简单地增加节点即可线性扩展计算和存储能力，无需停机
高可用性：基于 Raft 协议实现数据的多副本存储，自动故障转移，RPO = 0
强一致性：通过分布式事务保证数据的强一致性，支持 ACID 特性
开源生态：完全开源，采用 Apache 2.0 协议，拥有活跃的社区和丰富的生态工具
c.技术背景
传统单机数据库面临的挑战：
容量瓶颈：单机存储容量有限，难以应对数据爆炸式增长
性能瓶颈：单机 CPU、内存、IO 资源有限，无法满足高并发需求
可用性问题：单点故障风险高，主从复制存在数据丢失风险
扩展困难：垂直扩展成本高，水平扩展需要复杂的分库分表方案
---------------------------------------------------------------------------------------------------------
传统分库分表方案的问题：
业务侵入性强：需要在应用层实现分片逻辑，增加开发复杂度
跨分片查询困难：JOIN、聚合、排序等操作实现复杂，性能差
数据迁移复杂：扩容缩容需要数据迁移，影响业务
运维成本高：需要管理大量数据库实例，监控告警复杂
---------------------------------------------------------------------------------------------------------
TiDB 的解决方案：
透明分片：自动将数据分散到多个节点，对应用完全透明
分布式事务：支持跨节点的 ACID 事务，保证数据一致性
在线扩缩容：支持在线添加或删除节点，自动数据均衡
统一 SQL 接口：提供标准 SQL 接口，支持复杂查询和事务
02.对比
a.TiDB vs MySQL
TiDB MySQL
分布式架构 单机或主从架构
水平扩展 垂直扩展或分库分表
自动分片 需要手动分库分表
分布式事务 单机事务
---------------------------------------------------------------------------------------------------------
架构对比：
扩展性 TiDB 支持在线水平扩展，可扩展到数百TB MySQL 单机容量有限，扩展需要分库分表
高可用 基于 Raft 协议，自动故障转移，RPO = 0 主从复制，可能丢失数据
一致性 强一致性，支持分布式事务 单机强一致，分库分表需要应用层保证
HTAP 原生支持 OLTP + OLAP 主要支持 OLTP，OLAP 需要额外方案
---------------------------------------------------------------------------------------------------------
功能对比：
SQL 兼容性 兼容 MySQL 5.7 协议，部分语法有差异 完整 MySQL 语法
事务隔离级别 支持 SI 和 RC 隔离级别 支持四种隔离级别
索引类型 支持主键索引、唯一索引、普通索引 支持更多索引类型（全文索引等）
存储引擎 TiKV（行存）+ TiFlash（列存） InnoDB、MyISAM 等
---------------------------------------------------------------------------------------------------------
性能对比：
OLTP 性能 单机性能略低于 MySQL，但可水平扩展 单机性能优秀
OLAP 性能 通过 TiFlash 列存引擎性能优秀 需要额外的 OLAP 方案
写入性能 分布式事务有一定开销 单机写入性能好
查询性能 支持分布式并行查询 单机查询性能好
---------------------------------------------------------------------------------------------------------
使用场景：
TiDB 更适合：数据量大（TB 级以上）、需要水平扩展、需要高可用、需要 HTAP、需要分布式事务
MySQL 更适合：数据量小（GB 级）、单机性能足够、简单的主从架构、成本敏感
b.TiDB vs PostgreSQL
TiDB 是分布式数据库，PostgreSQL 是单机数据库
TiDB 兼容 MySQL 协议，PostgreSQL 有自己的协议
TiDB 原生支持 HTAP，PostgreSQL 主要支持 OLTP
TiDB 支持水平扩展，PostgreSQL 主要依赖垂直扩展
---------------------------------------------------------------------------------------------------------
TiDB 的分布式事务基于 Percolator 模型，PostgreSQL 使用 MVCC
TiDB 使用 Raft 协议保证一致性，PostgreSQL 使用流复制
TiDB 的列存引擎 TiFlash 提供 OLAP 能力，PostgreSQL 需要额外方案
TiDB 更适合大规模数据和高并发场景，PostgreSQL 更适合中小规模和复杂查询
c.TiDB vs 传统分库分表
TiDB 对应用透明，分库分表需要应用层改造
TiDB 支持跨分片事务，分库分表难以保证分布式事务
TiDB 支持跨分片 JOIN 和聚合，分库分表实现复杂
TiDB 支持在线扩缩容，分库分表扩容需要数据迁移
---------------------------------------------------------------------------------------------------------
TiDB 统一管理，分库分表需要管理多个数据库实例
TiDB 自动负载均衡，分库分表需要手动调整
TiDB 提供全局视图，分库分表需要应用层聚合
TiDB 降低开发和运维成本，分库分表增加复杂度
1.2 [1]概念
01.核心组件
a.TiDB Server
TiDB Server 是无状态的 SQL 层，负责接收客户端连接
它解析 SQL 语句，生成查询计划，协调分布式事务
TiDB Server 本身不存储数据，可以水平扩展
客户端可以连接到任意 TiDB Server 节点，通过负载均衡分发请求
---------------------------------------------------------------------------------------------------------
TiDB Server 兼容 MySQL 5.7 协议，支持大部分 MySQL 语法
它将 SQL 查询转换为对 TiKV 的 Key-Value 操作
TiDB Server 包含 SQL 解析器、查询优化器、执行器等模块
支持分布式事务协调、跨节点 JOIN、聚合等复杂操作
b.TiKV
TiKV 是分布式 Key-Value 存储引擎，负责存储数据
它基于 RocksDB 构建，使用 Raft 协议保证数据一致性
TiKV 将数据按照 Key 的范围分割成 Region，每个 Region 默认 96MB
每个 Region 有多个副本（默认3个），分布在不同的 TiKV 节点上
---------------------------------------------------------------------------------------------------------
TiKV 使用 Raft 协议进行数据复制和一致性保证
每个 Region 的多个副本组成一个 Raft Group
写入操作需要在 Raft Group 中达成多数派共识
TiKV 支持分布式事务，实现了 Percolator 事务模型
c.PD（Placement Driver）
PD 是集群的元数据管理和调度中心
它存储集群的拓扑信息、Region 的位置信息、统计信息等
PD 负责生成全局唯一的事务 ID（TSO）
PD 根据集群状态进行 Region 的调度和负载均衡
---------------------------------------------------------------------------------------------------------
PD 使用 etcd 存储元数据，通过 Raft 协议保证高可用
PD 集群通常部署 3 个或 5 个节点，采用奇数部署
PD 监控各个 TiKV 节点的状态，自动进行故障转移
PD 提供全局时钟服务（TSO），保证分布式事务的顺序性
d.TiFlash
TiFlash 是 TiDB 的列式存储扩展，用于加速 OLAP 查询
它通过 Raft Learner 协议从 TiKV 实时同步数据
TiFlash 将行存数据转换为列存格式，优化分析查询性能
TiFlash 与 TiDB 无缝集成，查询优化器自动选择最优存储引擎
---------------------------------------------------------------------------------------------------------
TiFlash 支持实时数据同步，延迟通常在秒级
它使用列式存储和向量化执行，大幅提升 OLAP 性能
TiFlash 可以与 TiKV 混合查询，实现真正的 HTAP
TiFlash 支持水平扩展，可以独立扩展 OLAP 能力
02.核心概念
a.Region
Region 是 TiKV 中数据分片的基本单位
TiKV 将整个 Key 空间按照 Key 的范围切分成多个 Region
每个 Region 默认大小为 96MB，当 Region 大小超过阈值时会自动分裂
Region 是数据调度和复制的基本单位
---------------------------------------------------------------------------------------------------------
每个 Region 包含一个连续的 Key 范围 [StartKey, EndKey)
Region 的多个副本组成一个 Raft Group，通过 Raft 协议保证一致性
Region 的副本分布在不同的 TiKV 节点上，提供高可用
PD 负责 Region 的调度，包括分裂、合并、迁移等操作
b.Raft Group
Raft Group 是 Region 的多个副本组成的复制组
每个 Raft Group 有一个 Leader 和多个 Follower
所有的读写请求都由 Leader 处理，Follower 负责数据备份
Leader 通过 Raft 协议将数据变更同步到 Follower
---------------------------------------------------------------------------------------------------------
写入操作需要在 Raft Group 中达成多数派共识（Quorum）
当 Leader 故障时，Follower 会自动选举出新的 Leader
Raft 协议保证数据的强一致性，不会丢失已提交的数据
TiKV 支持 Follower Read，可以从 Follower 读取数据，提升读性能
c.TSO（Timestamp Oracle）
TSO 是 PD 提供的全局时钟服务，用于生成全局唯一且单调递增的时间戳
每个分布式事务都需要从 PD 获取 TSO 作为事务的开始时间戳和提交时间戳
TSO 保证了分布式事务的顺序性和一致性
TSO 是 TiDB 实现分布式事务的关键组件
---------------------------------------------------------------------------------------------------------
TSO 由 PD Leader 节点生成，保证全局唯一性
TSO 包含物理时间和逻辑时间两部分
物理时间精确到毫秒，逻辑时间用于在同一毫秒内区分不同事务
TSO 的性能直接影响分布式事务的性能
d.MVCC（Multi-Version Concurrency Control）
TiDB 使用 MVCC 实现事务的隔离性
每个数据项可以有多个版本，每个版本对应一个时间戳
读操作读取小于等于事务开始时间戳的最新版本
写操作创建新版本，不影响其他事务的读操作
---------------------------------------------------------------------------------------------------------
MVCC 避免了读写冲突，提高了并发性能
旧版本的数据会被 GC（垃圾回收）机制清理
TiDB 的 MVCC 实现基于 Percolator 模型
MVCC 支持快照隔离（Snapshot Isolation）级别
03.术语表
a.基础术语
集群（Cluster）：由多个 TiDB Server、TiKV、PD 节点组成的分布式系统
节点（Node）：集群中的一个物理或虚拟服务器实例
副本（Replica）：Region 的一个数据拷贝，用于高可用和容错
分片（Shard）：数据的逻辑分区，在 TiDB 中对应 Region
---------------------------------------------------------------------------------------------------------
Leader：Raft Group 中负责处理读写请求的副本
Follower：Raft Group 中负责数据备份的副本
Learner：Raft Group 中的特殊角色，只接收日志不参与投票
Quorum：Raft 协议中的多数派，通常为 (N/2 + 1)
b.事务术语
乐观事务（Optimistic Transaction）：假设冲突较少，提交时检测冲突
悲观事务（Pessimistic Transaction）：提前加锁，避免冲突
快照隔离（Snapshot Isolation）：事务读取开始时刻的数据快照
读已提交（Read Committed）：事务只能读取已提交的数据
---------------------------------------------------------------------------------------------------------
两阶段提交（2PC）：分布式事务的提交协议，包括 Prewrite 和 Commit 阶段
Percolator：Google 提出的分布式事务模型，TiDB 基于此实现
事务冲突（Transaction Conflict）：多个事务同时修改同一数据
锁（Lock）：用于保护数据的并发控制机制
c.存储术语
行存（Row Store）：按行存储数据，适合 OLTP 场景，对应 TiKV
列存（Column Store）：按列存储数据，适合 OLAP 场景，对应 TiFlash
RocksDB：TiKV 底层使用的嵌入式 Key-Value 存储引擎
LSM-Tree：Log-Structured Merge-Tree，RocksDB 使用的数据结构
---------------------------------------------------------------------------------------------------------
Compaction：LSM-Tree 的数据整理过程，合并多层数据
SST（Sorted String Table）：RocksDB 中的数据文件格式
WAL（Write-Ahead Log）：预写日志，保证数据持久性
Memtable：RocksDB 的内存数据结构，接收写入操作
d.运维术语
扩容（Scale Out）：增加节点以提升集群容量和性能
缩容（Scale In）：减少节点以降低成本
负载均衡（Load Balance）：将数据和请求均匀分布到各个节点
热点（Hotspot）：访问集中的数据或节点，可能导致性能瓶颈
---------------------------------------------------------------------------------------------------------
GC（Garbage Collection）：清理 MVCC 旧版本数据的过程
BR（Backup & Restore）：TiDB 的备份恢复工具
DM（Data Migration）：TiDB 的数据迁移工具
TiUP：TiDB 的部署和运维工具
1.3 [1]优缺点
01.优势
a.水平扩展能力
TiDB 支持在线水平扩展，通过增加节点即可线性提升性能和容量
扩容过程对业务完全透明，无需停机或修改应用代码
支持独立扩展计算层（TiDB Server）和存储层（TiKV）
可以根据业务需求灵活调整集群规模，实现弹性伸缩
---------------------------------------------------------------------------------------------------------
扩展过程自动进行数据均衡，无需手动干预
支持从几个节点扩展到数百个节点
存储容量可扩展到 PB 级别
性能随节点数量近似线性增长
b.高可用性
基于 Raft 协议实现数据的多副本存储，默认3副本
自动故障检测和故障转移，通常在30秒内完成
RPO（Recovery Point Objective）= 0，不会丢失已提交的数据
RTO（Recovery Time Objective）< 30秒，快速恢复服务
---------------------------------------------------------------------------------------------------------
支持跨数据中心部署，实现异地容灾
PD 集群采用 Raft 协议，保证元数据高可用
TiDB Server 无状态，任意节点故障不影响服务
支持在线升级，不影响业务运行
c.强一致性
支持分布式事务，保证 ACID 特性
使用 Percolator 事务模型，提供快照隔离级别
通过 TSO 保证全局事务顺序
读写操作都保证强一致性，不会读到脏数据
---------------------------------------------------------------------------------------------------------
支持悲观事务和乐观事务两种模式
跨 Region 事务保证原子性
事务冲突检测机制完善
提供与单机数据库一致的事务语义
d.MySQL兼容性
高度兼容 MySQL 5.7 协议，大部分应用可以无缝迁移
支持 MySQL 客户端和驱动程序
兼容大部分 MySQL 语法和函数
支持 MySQL 的权限管理和认证机制
---------------------------------------------------------------------------------------------------------
可以使用 MySQL 生态工具，如 Navicat、DBeaver 等
支持 MySQL 的备份恢复工具
降低学习成本和迁移成本
方便从 MySQL 平滑迁移到 TiDB
e.HTAP能力
同时支持 OLTP 和 OLAP 场景，一套系统解决两类需求
TiKV 提供行存引擎，优化事务处理性能
TiFlash 提供列存引擎，优化分析查询性能
查询优化器自动选择最优存储引擎
---------------------------------------------------------------------------------------------------------
实时数据同步，无需 ETL 过程
避免维护多套系统的复杂性和成本
支持混合负载，事务和分析互不影响
降低数据一致性问题和数据延迟
f.云原生架构
存储和计算分离，支持独立扩展
无状态的 SQL 层，支持快速弹性伸缩
容器化部署，支持 Kubernetes
支持公有云、私有云、混合云部署
---------------------------------------------------------------------------------------------------------
资源利用率高，按需分配
支持多租户隔离
与云原生生态无缝集成
降低运维复杂度
02.劣势
a.单机性能
由于分布式架构的开销，单机性能略低于 MySQL
分布式事务需要多次网络通信，延迟相对较高
小数据量场景下，性能优势不明显
简单查询的响应时间可能略长于单机数据库
---------------------------------------------------------------------------------------------------------
适合大数据量和高并发场景
不适合对延迟极度敏感的场景
需要权衡分布式能力和单机性能
建议数据量在 TB 级以上使用
b.运维复杂度
分布式系统的运维比单机数据库复杂
需要监控多个组件（TiDB、TiKV、PD）
故障排查需要更多的专业知识
需要理解分布式系统的原理和特性
---------------------------------------------------------------------------------------------------------
需要配置更多的监控指标
日志分析和问题定位相对复杂
需要专业的 DBA 团队
学习曲线相对陡峭
c.资源消耗
分布式架构需要更多的服务器资源
至少需要 6 个节点（3个 TiKV + 3个 PD）才能保证高可用
多副本存储导致存储成本增加（默认3倍）
网络带宽消耗较大
---------------------------------------------------------------------------------------------------------
小规模部署的成本较高
不适合资源受限的环境
需要考虑硬件成本和运维成本
建议在云环境中使用以降低成本
d.生态成熟度
相比 MySQL 和 PostgreSQL，生态相对不够成熟
部分 MySQL 特性不支持或支持不完善
第三方工具和插件相对较少
社区规模相对较小
---------------------------------------------------------------------------------------------------------
部分高级特性仍在开发中
文档和案例相对较少
遇到问题时可参考的资料有限
需要依赖官方支持
03.适用性评估
a.适合使用TiDB的场景
数据量大：单表数据量超过 1TB，或总数据量超过 10TB
需要水平扩展：预期数据量会持续增长，需要弹性扩展能力
高可用要求：对数据可靠性和服务可用性要求高，不能接受数据丢失
需要 HTAP：既有事务处理需求，又有实时分析需求
---------------------------------------------------------------------------------------------------------
分库分表痛点：现有分库分表方案维护困难，希望简化架构
MySQL 瓶颈：MySQL 单机性能或容量达到瓶颈，需要分布式方案
强一致性：需要分布式事务和强一致性保证
云原生：希望在云环境中部署，需要弹性伸缩能力
b.不适合使用TiDB的场景
数据量小：总数据量小于 100GB，单机数据库足够
低延迟要求：对单次查询延迟要求极高（毫秒级）
资源受限：硬件资源有限，无法部署分布式集群
简单应用：业务逻辑简单，不需要复杂的分布式特性
---------------------------------------------------------------------------------------------------------
成本敏感：预算有限，无法承担分布式系统的成本
运维能力不足：缺乏分布式系统运维经验和团队
特殊功能依赖：依赖 MySQL 特有的功能（如全文索引、空间索引等）
短期项目：项目周期短，不值得投入分布式系统的学习成本
1.4 [1]使用场景
01.典型应用场景
a.金融行业
支付系统：处理高并发的支付交易，保证数据强一致性和高可用
核心账务系统：管理海量账户数据，支持复杂的账务查询和分析
风控系统：实时分析交易数据，识别异常行为和风险
清算系统：处理大量的清算数据，保证数据准确性
---------------------------------------------------------------------------------------------------------
金融行业对数据一致性和可靠性要求极高，TiDB 的 ACID 特性和高可用能力非常适合
支持实时风控分析，无需将数据导出到其他系统
可以替代传统的分库分表方案，简化架构
满足金融监管对数据安全和审计的要求
b.电商平台
订单系统：处理高并发的订单创建和查询，支持分布式事务
库存系统：实时更新库存，避免超卖问题
用户系统：管理海量用户数据，支持用户画像分析
商品系统：存储商品信息和属性，支持复杂的商品搜索
---------------------------------------------------------------------------------------------------------
电商业务具有明显的峰值特征（如双11），TiDB 的弹性扩展能力可以应对流量高峰
支持实时数据分析，帮助运营决策
可以统一 OLTP 和 OLAP，简化数据架构
降低分库分表带来的开发和运维成本
c.互联网应用
社交网络：存储用户关系和动态，支持复杂的社交查询
内容平台：管理海量的内容数据，支持个性化推荐
游戏平台：存储玩家数据和游戏状态，支持高并发访问
物联网：存储海量的设备数据和时序数据
---------------------------------------------------------------------------------------------------------
互联网应用的数据量增长快，TiDB 的水平扩展能力可以应对数据增长
支持实时数据分析，优化用户体验
降低数据库运维成本，让团队专注于业务开发
支持多租户场景，实现资源隔离
d.企业应用
ERP 系统：管理企业资源，支持复杂的业务流程
CRM 系统：管理客户关系，支持客户数据分析
数据中台：统一管理企业数据，支持数据共享和分析
日志系统：存储和分析海量日志数据
---------------------------------------------------------------------------------------------------------
企业应用需要高可用和数据一致性，TiDB 可以满足这些要求
支持复杂的业务逻辑和查询
降低数据孤岛问题，实现数据统一管理
支持数据治理和合规要求
02.业务特征
a.数据量大
单表数据量超过 1TB，或总数据量超过 10TB
数据持续增长，预期会达到 PB 级别
单机数据库无法满足存储需求
需要分布式存储和计算能力
---------------------------------------------------------------------------------------------------------
TiDB 支持水平扩展，可以轻松应对数据增长
存储容量可扩展到 PB 级别
性能随数据量增长保持稳定
无需担心单机容量瓶颈
b.高并发
需要支持每秒数万甚至数十万的请求
业务有明显的峰值特征，需要弹性扩展
单机数据库无法满足并发需求
需要分布式架构分担负载
---------------------------------------------------------------------------------------------------------
TiDB 支持水平扩展计算能力
可以根据业务需求动态调整节点数量
支持读写分离，提升读性能
降低单点压力，提高系统稳定性
c.强一致性
对数据一致性要求高，不能接受数据丢失或不一致
需要支持分布式事务
需要跨节点的 ACID 保证
业务逻辑复杂，需要事务支持
---------------------------------------------------------------------------------------------------------
TiDB 提供分布式事务，保证 ACID 特性
使用 Raft 协议保证数据一致性
RPO = 0，不会丢失已提交的数据
支持跨节点的复杂事务
d.实时分析
需要对业务数据进行实时分析
不希望维护单独的 OLAP 系统
需要统一的数据视图，避免数据不一致
希望降低 ETL 的复杂度和延迟
---------------------------------------------------------------------------------------------------------
TiDB 的 HTAP 能力可以同时支持 OLTP 和 OLAP
TiFlash 提供实时的列存引擎
无需数据导出，直接在线分析
降低系统复杂度和维护成本
03.迁移场景
a.从MySQL迁移
MySQL 单机容量或性能达到瓶颈
现有分库分表方案维护困难
需要更好的高可用和扩展能力
希望简化数据库架构
---------------------------------------------------------------------------------------------------------
TiDB 高度兼容 MySQL，迁移成本低
可以使用 DM 工具实现在线迁移
支持增量同步，降低停机时间
迁移后应用代码基本无需修改
b.从Oracle迁移
希望降低数据库许可成本
需要云原生的分布式能力
希望使用开源技术栈
需要更好的水平扩展能力
---------------------------------------------------------------------------------------------------------
TiDB 是开源免费的，无需许可费用
支持分布式架构，扩展能力更强
可以使用迁移工具辅助迁移
需要改造部分 Oracle 特有的语法和功能
c.从分库分表迁移
分库分表方案维护困难，开发效率低
跨分片查询和事务实现复杂
扩容缩容需要数据迁移，影响业务
希望简化架构，降低运维成本
---------------------------------------------------------------------------------------------------------
TiDB 提供透明的分布式能力，无需应用层分片
支持跨节点的 JOIN 和事务
在线扩缩容，无需数据迁移
大幅降低开发和运维成本
d.从NoSQL迁移
NoSQL 缺乏事务支持，数据一致性难以保证
缺乏标准 SQL 接口，查询复杂
需要关系型数据库的特性
希望统一数据存储方案
---------------------------------------------------------------------------------------------------------
TiDB 提供完整的事务支持
支持标准 SQL 接口，查询更灵活
兼顾 NoSQL 的扩展能力和关系型数据库的特性
降低多套系统的维护成本
1.5 [2]架构
01.整体架构
a.三层架构
TiDB 采用存储和计算分离的三层架构设计
SQL 层（TiDB Server）：无状态的 SQL 处理层，负责接收客户端请求、解析 SQL、生成执行计划
存储层（TiKV/TiFlash）：分布式存储层，负责数据持久化和事务处理
调度层（PD）：集群管理和调度中心，负责元数据管理和全局调度
---------------------------------------------------------------------------------------------------------
三层架构实现了职责分离，每层可以独立扩展
SQL 层无状态，可以水平扩展以提升并发处理能力
存储层分布式，可以水平扩展以提升存储容量和吞吐量
调度层高可用，通过 Raft 协议保证元数据的一致性
b.数据流转
客户端连接到任意 TiDB Server 节点
TiDB Server 解析 SQL，生成查询计划
TiDB Server 将 SQL 操作转换为 Key-Value 操作
TiDB Server 向 TiKV 发起读写请求
---------------------------------------------------------------------------------------------------------
TiKV 处理 Key-Value 操作，返回结果给 TiDB Server
TiDB Server 聚合结果，返回给客户端
PD 提供 TSO 服务，协调分布式事务
PD 监控集群状态，进行 Region 调度
c.存储计算分离
存储层和计算层物理分离，可以独立扩展
TiDB Server 不存储数据，只负责计算
TiKV 负责数据存储，不负责 SQL 处理
这种架构提供了更好的弹性和资源利用率
---------------------------------------------------------------------------------------------------------
可以根据业务特点独立扩展计算或存储
计算层故障不影响数据安全
存储层故障可以快速恢复
支持云原生的弹性伸缩
02.TiDB Server架构
a.组件模块
Protocol Layer：实现 MySQL 协议，处理客户端连接
Parser：解析 SQL 语句，生成抽象语法树（AST）
Optimizer：查询优化器，生成最优执行计划
Executor：执行器，执行查询计划
---------------------------------------------------------------------------------------------------------
DistSQL：分布式 SQL 执行引擎，将计算下推到 TiKV
Transaction Coordinator：事务协调器，协调分布式事务
Region Cache：缓存 Region 的位置信息
PD Client：与 PD 通信，获取 TSO 和元数据
b.查询处理流程
接收客户端 SQL 请求
Parser 解析 SQL，生成 AST
Validator 验证 SQL 语法和权限
Optimizer 生成查询计划
---------------------------------------------------------------------------------------------------------
Executor 执行查询计划
DistSQL 将计算下推到 TiKV
聚合 TiKV 返回的结果
返回结果给客户端
c.无状态设计
TiDB Server 不存储任何数据
所有状态信息都存储在 TiKV 和 PD 中
TiDB Server 可以随时添加或删除
客户端可以连接到任意 TiDB Server 节点
---------------------------------------------------------------------------------------------------------
通过负载均衡器分发请求
节点故障时自动切换到其他节点
支持水平扩展，提升并发处理能力
简化运维，降低故障影响
03.TiKV架构
a.存储引擎
TiKV 基于 RocksDB 构建，RocksDB 是一个高性能的嵌入式 Key-Value 存储引擎
使用 LSM-Tree 数据结构，优化写入性能
支持列族（Column Family），实现逻辑隔离
提供快照（Snapshot）功能，支持一致性读取
---------------------------------------------------------------------------------------------------------
RocksDB 将数据存储在 SST 文件中
使用 WAL（Write-Ahead Log）保证数据持久性
通过 Compaction 整理数据，优化读性能
支持数据压缩，降低存储成本
b.Raft协议
TiKV 使用 Raft 协议实现数据复制和一致性
每个 Region 的多个副本组成一个 Raft Group
Raft Group 中有一个 Leader 和多个 Follower
所有写入操作都由 Leader 处理
---------------------------------------------------------------------------------------------------------
Leader 将日志复制到 Follower
当多数派确认后，日志被提交
Follower 应用已提交的日志
Leader 故障时，Follower 自动选举新 Leader
c.Region分片
TiKV 将数据按 Key 范围切分成 Region
每个 Region 默认 96MB，可配置
Region 自动分裂和合并
Region 是数据调度的基本单位
---------------------------------------------------------------------------------------------------------
Region 的副本分布在不同的 TiKV 节点上
PD 负责 Region 的调度和负载均衡
支持 Region 的在线迁移
Region 分裂和合并对应用透明
d.事务处理
TiKV 实现了 Percolator 事务模型
支持分布式事务，保证 ACID 特性
使用 MVCC 实现事务隔离
支持乐观事务和悲观事务
---------------------------------------------------------------------------------------------------------
乐观事务：假设冲突较少，提交时检测冲突
悲观事务：提前加锁，避免冲突
事务使用两阶段提交（2PC）协议
通过 TSO 保证事务的顺序性
04.PD架构
a.核心功能
元数据管理：存储集群拓扑、Region 位置、统计信息
TSO 服务：提供全局唯一且单调递增的时间戳
Region 调度：根据集群状态调度 Region，实现负载均衡
集群监控：监控各节点的状态和性能指标
---------------------------------------------------------------------------------------------------------
PD 使用 etcd 存储元数据
PD 集群通过 Raft 协议保证高可用
PD Leader 负责生成 TSO 和调度决策
PD Follower 同步数据，提供读服务
b.调度策略
负载均衡：将 Region 均匀分布到各个 TiKV 节点
热点调度：将热点 Region 迁移到负载较低的节点
故障恢复：检测节点故障，迁移 Region 到健康节点
副本补齐：保证每个 Region 有足够的副本数
---------------------------------------------------------------------------------------------------------
Region 分裂：当 Region 超过阈值时自动分裂
Region 合并：当 Region 过小时自动合并
跨机架调度：保证副本分布在不同的机架
资源隔离：支持标签调度，实现资源隔离
c.高可用设计
PD 集群通常部署 3 个或 5 个节点
使用 Raft 协议保证数据一致性
Leader 故障时自动选举新 Leader
Follower 可以提供读服务
---------------------------------------------------------------------------------------------------------
etcd 存储元数据，保证数据持久性
支持跨数据中心部署
监控 PD 集群状态，及时告警
定期备份 PD 数据
05.TiFlash架构
a.列存引擎
TiFlash 是 TiDB 的列式存储扩展
使用列式存储格式，优化 OLAP 查询
支持向量化执行，提升计算性能
与 TiDB 无缝集成，自动选择存储引擎
---------------------------------------------------------------------------------------------------------
列存储适合扫描大量数据的分析查询
向量化执行利用 SIMD 指令加速计算
支持数据压缩，降低存储成本
提供与 TiKV 一致的数据视图
b.数据同步
TiFlash 通过 Raft Learner 协议从 TiKV 同步数据
实时同步，延迟通常在秒级
不参与 Raft 投票，不影响 TiKV 性能
自动将行存数据转换为列存格式
---------------------------------------------------------------------------------------------------------
支持增量同步，只同步变更数据
同步过程对业务透明
支持选择性同步，只同步需要的表
保证数据一致性，不会读到脏数据
c.查询加速
TiFlash 大幅提升 OLAP 查询性能
列存储减少 IO，只读取需要的列
向量化执行提升 CPU 利用率
支持并行查询，充分利用多核
---------------------------------------------------------------------------------------------------------
查询优化器自动选择 TiKV 或 TiFlash
可以混合查询 TiKV 和 TiFlash
支持索引加速，进一步提升性能
适合复杂的聚合和分析查询
1.6 [2]核心特性
01.分布式事务
a.Percolator模型
TiDB 基于 Google Percolator 模型实现分布式事务
使用两阶段提交（2PC）协议保证事务原子性
通过 MVCC 实现事务隔离
使用 TSO 保证事务顺序
---------------------------------------------------------------------------------------------------------
Percolator 是一个建立在 Bigtable 之上的分布式事务系统
TiDB 将其移植到 TiKV 之上
支持跨 Region 的分布式事务
保证 ACID 特性
b.两阶段提交
Prewrite 阶段：在所有涉及的 Region 上写入锁和数据
Commit 阶段：提交事务，清理锁
如果 Prewrite 失败，事务回滚
如果 Commit 失败，后台异步清理
---------------------------------------------------------------------------------------------------------
使用主键（Primary Key）协调事务状态
其他键（Secondary Keys）依赖主键的状态
通过 TSO 确定事务的提交顺序
支持事务冲突检测和重试
c.乐观事务与悲观事务
乐观事务：假设冲突较少，提交时检测冲突，适合读多写少场景
悲观事务：提前加锁，避免冲突，适合写冲突较多场景
TiDB 默认使用悲观事务模式
可以通过配置切换事务模式
---------------------------------------------------------------------------------------------------------
乐观事务性能更高，但冲突时需要重试
悲观事务避免重试，但加锁有开销
可以在会话级别设置事务模式
根据业务特点选择合适的模式
d.隔离级别
TiDB 支持快照隔离（Snapshot Isolation）和读已提交（Read Committed）
快照隔离：事务读取开始时刻的数据快照，避免幻读
读已提交：事务只能读取已提交的数据，避免脏读
默认使用快照隔离级别
---------------------------------------------------------------------------------------------------------
快照隔离接近于可重复读（Repeatable Read）
通过 MVCC 实现，读写不阻塞
支持 SELECT FOR UPDATE 加锁读
可以通过配置调整隔离级别
02.水平扩展
a.在线扩容
TiDB 支持在线添加节点，无需停机
扩容过程对业务完全透明
自动进行数据均衡，无需手动干预
扩容后性能和容量线性提升
---------------------------------------------------------------------------------------------------------
可以独立扩展 TiDB Server、TiKV、TiFlash
扩容过程中业务不受影响
PD 自动调度 Region 到新节点
支持滚动扩容，逐步增加节点
b.在线缩容
TiDB 支持在线删除节点，无需停机
缩容前自动迁移数据到其他节点
缩容过程对业务完全透明
可以根据业务需求灵活调整集群规模
---------------------------------------------------------------------------------------------------------
PD 自动将 Region 迁移到其他节点
确保副本数满足要求后才删除节点
缩容过程中业务不受影响
支持滚动缩容，逐步减少节点
c.弹性伸缩
支持根据业务负载动态调整集群规模
可以在业务高峰期扩容，低峰期缩容
降低资源成本，提高资源利用率
特别适合云环境中的弹性部署
---------------------------------------------------------------------------------------------------------
可以与 Kubernetes 集成，实现自动伸缩
支持定时伸缩，应对可预测的流量变化
支持基于指标的自动伸缩
实现真正的云原生弹性
d.负载均衡
PD 自动进行 Region 调度，实现负载均衡
将热点 Region 迁移到负载较低的节点
保证各节点的负载相对均衡
提升集群整体性能
---------------------------------------------------------------------------------------------------------
支持多种调度策略，如负载均衡、热点调度等
可以配置调度参数，调整调度行为
监控各节点的负载情况
自动检测和处理热点问题
03.高可用
a.多副本存储
每个 Region 默认有 3 个副本
副本分布在不同的 TiKV 节点上
通过 Raft 协议保证副本一致性
任意副本故障不影响数据可用性
---------------------------------------------------------------------------------------------------------
可以配置副本数，通常为 3 或 5
副本数越多，可用性越高，但存储成本越高
支持跨机架、跨数据中心部署
保证数据的持久性和可靠性
b.自动故障转移
TiKV 节点故障时，Raft 自动选举新 Leader
通常在 30 秒内完成故障转移
PD 检测到节点故障后，自动调度 Region
TiDB Server 故障时，客户端自动切换到其他节点
---------------------------------------------------------------------------------------------------------
故障转移过程对业务影响最小
RPO = 0，不会丢失已提交的数据
RTO < 30 秒，快速恢复服务
支持自动恢复，无需人工干预
c.数据一致性
使用 Raft 协议保证数据强一致性
写入操作需要多数派确认
读取操作从 Leader 读取，保证一致性
支持 Follower Read，提升读性能
---------------------------------------------------------------------------------------------------------
不会出现脑裂问题
保证已提交的数据不会丢失
支持线性一致性读取
提供与单机数据库一致的数据视图
d.跨数据中心部署
支持跨数据中心部署，实现异地容灾
可以配置副本在不同数据中心的分布
支持多活架构，提升可用性
降低单数据中心故障的影响
---------------------------------------------------------------------------------------------------------
需要考虑网络延迟对性能的影响
可以配置就近读取，降低延迟
支持数据中心级别的故障转移
满足监管和合规要求
04.HTAP能力
a.行列混合存储
TiKV 提供行存引擎，优化 OLTP 性能
TiFlash 提供列存引擎，优化 OLAP 性能
两种存储引擎数据实时同步
查询优化器自动选择最优引擎
---------------------------------------------------------------------------------------------------------
行存适合点查询和事务处理
列存适合扫描和聚合查询
可以混合查询两种引擎
实现真正的 HTAP
b.实时同步
TiFlash 通过 Raft Learner 从 TiKV 实时同步数据
同步延迟通常在秒级
无需 ETL 过程
保证数据一致性
---------------------------------------------------------------------------------------------------------
支持增量同步，只同步变更数据
同步过程对 OLTP 性能影响极小
可以选择性同步需要的表
降低数据延迟和不一致问题
c.查询优化
查询优化器根据查询类型选择存储引擎
点查询和事务使用 TiKV
扫描和聚合查询使用 TiFlash
可以通过 Hint 强制指定引擎
---------------------------------------------------------------------------------------------------------
优化器基于成本模型选择执行计划
考虑数据分布、索引、统计信息等因素
支持并行查询，提升性能
提供 EXPLAIN 分析查询计划
d.统一SQL接口
OLTP 和 OLAP 使用统一的 SQL 接口
无需维护多套系统
降低开发和运维复杂度
避免数据一致性问题
---------------------------------------------------------------------------------------------------------
支持标准 SQL 语法
兼容 MySQL 协议和工具
简化应用开发
提升开发效率
1.7 [2]版本演进
01.早期版本（1.0-2.x）
a.TiDB 1.0（2017年10月）
第一个 GA 版本，标志着 TiDB 正式可用于生产环境
实现了基本的分布式事务和 SQL 功能
支持 MySQL 协议兼容
提供基础的高可用和扩展能力
---------------------------------------------------------------------------------------------------------
基于 Percolator 模型实现分布式事务
使用 Raft 协议保证数据一致性
支持在线扩缩容
提供基础的监控和运维工具
b.TiDB 2.0（2018年4月）
大幅提升性能和稳定性
引入 TiSpark，支持 Spark 分析
改进查询优化器
增强监控和诊断能力
---------------------------------------------------------------------------------------------------------
性能提升 50% 以上
支持更多 MySQL 语法和函数
改进 Region 调度算法
提供更完善的文档和工具
c.TiDB 2.1（2018年11月）
引入悲观事务模型
支持窗口函数
改进 SQL 优化器
增强稳定性和性能
---------------------------------------------------------------------------------------------------------
悲观事务降低冲突重试
支持更复杂的 SQL 查询
改进 GC 机制
优化内存使用
02.HTAP时代（3.0-4.x）
a.TiDB 3.0（2019年6月）
引入 TiFlash 列存引擎，实现 HTAP
大幅提升 OLAP 性能
改进事务模型
增强易用性
---------------------------------------------------------------------------------------------------------
TiFlash 提供实时列存
支持混合负载
改进查询优化器
提供更好的监控和诊断工具
b.TiDB 4.0（2020年5月）
引入 TiDB Dashboard，提升易用性
支持 Backup & Restore（BR）工具
引入 TiCDC 变更数据捕获
改进 TiFlash 性能
---------------------------------------------------------------------------------------------------------
Dashboard 提供可视化管理界面
BR 提供快速备份恢复
TiCDC 支持数据同步和订阅
性能和稳定性持续提升
03.云原生时代（5.0-7.x）
a.TiDB 5.0（2021年4月）
引入 MPP（Massively Parallel Processing）架构
大幅提升 OLAP 性能
支持聚簇索引
引入弹性调度
---------------------------------------------------------------------------------------------------------
MPP 架构提供分布式计算能力
OLAP 性能提升 10 倍以上
聚簇索引优化存储和查询
支持更灵活的资源调度
b.TiDB 5.4（2022年2月）
引入 GBK 字符集支持
改进 TiFlash 性能
增强安全特性
优化资源管控
---------------------------------------------------------------------------------------------------------
支持更多字符集
TiFlash 性能持续优化
提供更细粒度的权限控制
支持资源隔离和限流
c.TiDB 6.0（2022年6月）
引入 Placement Rules in SQL
支持数据放置策略
改进 HTAP 性能
增强云原生能力
---------------------------------------------------------------------------------------------------------
通过 SQL 控制数据放置
支持多租户隔离
HTAP 性能进一步提升
更好地支持 Kubernetes
d.TiDB 7.0（2023年6月）
引入分布式并行执行框架
大幅提升 OLTP 性能
改进资源管控
增强可观测性
---------------------------------------------------------------------------------------------------------
并行执行提升事务性能
支持更细粒度的资源控制
提供更丰富的监控指标
持续优化云原生能力
04.最新发展（8.0+）
a.TiDB 8.0（2024年）
持续优化性能和稳定性
增强 AI 和向量数据库能力
改进开发者体验
提升云原生成熟度
---------------------------------------------------------------------------------------------------------
支持向量检索
集成 AI 能力
提供更友好的开发工具
更好地支持 Serverless
b.未来方向
持续提升 HTAP 性能
增强 AI 和机器学习能力
改进 Serverless 支持
提升易用性和开发者体验
---------------------------------------------------------------------------------------------------------
探索新的存储和计算技术
支持更多的数据类型和功能
降低使用门槛
扩展生态系统
05.版本选择建议
a.生产环境
建议使用 LTS（Long Term Support）版本
当前推荐 TiDB 7.5 LTS 或更高版本
LTS 版本提供长期支持和稳定性保证
定期更新补丁版本，修复 bug 和安全问题
---------------------------------------------------------------------------------------------------------
避免使用过旧的版本
关注官方发布的安全公告
制定升级计划，定期升级版本
在测试环境充分测试后再升级生产环境
b.新项目
可以选择最新的稳定版本
享受最新的特性和性能优化
关注社区反馈和已知问题
评估新特性对业务的价值
---------------------------------------------------------------------------------------------------------
最新版本通常有更好的性能
支持更多的功能和特性
但可能存在未发现的问题
需要权衡新特性和稳定性
c.升级策略
制定详细的升级计划
在测试环境充分测试
使用滚动升级，降低影响
准备回滚方案
---------------------------------------------------------------------------------------------------------
阅读版本发布说明，了解变更
评估不兼容的变更
备份数据，确保可以恢复
监控升级过程，及时发现问题
2 TiDB基础
2.1 汇总：6个
00.汇总
数据库与表 创建、修改、删除数据库和表
数据类型 数值、字符串、日期时间、JSON 等类型
索引 主键索引、唯一索引、普通索引、表达式索引
事务模型 乐观事务、悲观事务、隔离级别
SQL语法 DDL、DML、DQL、DCL 语句
与MySQL兼容性 兼容性说明、差异对比、迁移注意事项
2.2 [1]数据库与表
01.数据库操作
a.创建数据库
使用 CREATE DATABASE 语句创建数据库
可以指定字符集和排序规则
支持 IF NOT EXISTS 子句避免重复创建
示例：CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
---------------------------------------------------------------------------------------------------------
TiDB 支持多个数据库，每个数据库独立管理
数据库名称区分大小写（取决于操作系统）
建议使用小写字母和下划线命名
避免使用 MySQL 保留字作为数据库名
b.查看数据库
SHOW DATABASES：列出所有数据库
SHOW CREATE DATABASE：查看数据库创建语句
USE database_name：切换当前数据库
SELECT DATABASE()：查看当前数据库
---------------------------------------------------------------------------------------------------------
可以通过 information_schema 查询数据库信息
SHOW DATABASES LIKE 'pattern'：模糊匹配数据库名
系统数据库包括 mysql、information_schema、performance_schema 等
不建议直接操作系统数据库
c.修改数据库
ALTER DATABASE 修改数据库属性
可以修改字符集和排序规则
示例：ALTER DATABASE mydb CHARACTER SET utf8mb4;
修改操作需要相应的权限
---------------------------------------------------------------------------------------------------------
修改字符集不会影响已存在的表
已存在的表需要单独修改
建议在创建时就指定正确的字符集
避免频繁修改数据库属性
d.删除数据库
DROP DATABASE 删除数据库
删除操作不可恢复，需谨慎使用
支持 IF EXISTS 子句避免错误
示例：DROP DATABASE IF EXISTS mydb;
---------------------------------------------------------------------------------------------------------
删除数据库会删除其中的所有表和数据
删除前建议先备份数据
需要 DROP 权限
删除操作会自动提交当前事务
02.表操作
a.创建表
使用 CREATE TABLE 语句创建表
需要指定列名、数据类型、约束等
支持主键、唯一键、外键、索引等约束
可以指定表的存储引擎和字符集
---------------------------------------------------------------------------------------------------------
示例：CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50), email VARCHAR(100) UNIQUE);
支持 IF NOT EXISTS 子句
可以使用 LIKE 或 AS SELECT 创建表
建议为每个表定义主键
b.查看表
SHOW TABLES：列出当前数据库的所有表
SHOW CREATE TABLE：查看表的创建语句
DESC table_name 或 DESCRIBE table_name：查看表结构
SHOW COLUMNS FROM table_name：查看列信息
---------------------------------------------------------------------------------------------------------
SHOW TABLE STATUS：查看表的状态信息
可以通过 information_schema.tables 查询表信息
SHOW FULL COLUMNS FROM table_name：查看详细列信息
SHOW INDEX FROM table_name：查看索引信息
c.修改表
ALTER TABLE 修改表结构
可以添加、删除、修改列
可以添加、删除索引和约束
可以修改表名、字符集等属性
---------------------------------------------------------------------------------------------------------
添加列：ALTER TABLE users ADD COLUMN age INT;
删除列：ALTER TABLE users DROP COLUMN age;
修改列：ALTER TABLE users MODIFY COLUMN name VARCHAR(100);
重命名列：ALTER TABLE users CHANGE COLUMN name username VARCHAR(50);
---------------------------------------------------------------------------------------------------------
添加索引：ALTER TABLE users ADD INDEX idx_email (email);
删除索引：ALTER TABLE users DROP INDEX idx_email;
重命名表：ALTER TABLE users RENAME TO members;
修改表操作可能需要较长时间，建议在低峰期执行
d.删除表
DROP TABLE 删除表
删除操作不可恢复，需谨慎使用
支持 IF EXISTS 子句
可以同时删除多个表
---------------------------------------------------------------------------------------------------------
示例：DROP TABLE IF EXISTS users, orders;
TRUNCATE TABLE 清空表数据但保留表结构
TRUNCATE 比 DELETE 更快，但不能回滚
删除表会自动删除相关的索引和约束
03.表约束
a.主键约束
PRIMARY KEY 定义主键
主键列的值必须唯一且不能为 NULL
每个表只能有一个主键
主键可以是单列或多列组合
---------------------------------------------------------------------------------------------------------
示例：CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50));
复合主键：CREATE TABLE orders (user_id INT, order_id INT, PRIMARY KEY (user_id, order_id));
TiDB 会为主键自动创建索引
建议使用自增主键或 UUID
b.唯一约束
UNIQUE 定义唯一约束
唯一列的值必须唯一，但可以为 NULL
一个表可以有多个唯一约束
唯一约束会自动创建唯一索引
---------------------------------------------------------------------------------------------------------
示例：CREATE TABLE users (id INT PRIMARY KEY, email VARCHAR(100) UNIQUE);
复合唯一约束：UNIQUE (col1, col2)
NULL 值不参与唯一性检查
可以通过 ALTER TABLE 添加或删除唯一约束
c.非空约束
NOT NULL 定义非空约束
非空列的值不能为 NULL
可以与其他约束组合使用
示例：CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50) NOT NULL);
---------------------------------------------------------------------------------------------------------
主键列默认为 NOT NULL
建议为重要字段添加 NOT NULL 约束
NULL 和空字符串是不同的
非空约束在插入和更新时检查
d.默认值约束
DEFAULT 定义默认值
插入数据时如果未指定值，使用默认值
默认值可以是常量或表达式
示例：CREATE TABLE users (id INT PRIMARY KEY, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP);
---------------------------------------------------------------------------------------------------------
支持 DEFAULT NULL
可以使用函数作为默认值，如 NOW()、UUID()
修改默认值不影响已存在的数据
DEFAULT 可以与 NOT NULL 组合使用
e.检查约束
CHECK 定义检查约束
检查约束用于限制列的取值范围
TiDB 支持 CHECK 约束（从 v3.0 开始）
示例：CREATE TABLE users (id INT PRIMARY KEY, age INT CHECK (age >= 0 AND age <= 150));
---------------------------------------------------------------------------------------------------------
检查约束在插入和更新时检查
可以引用同一行的其他列
复杂的检查逻辑建议在应用层实现
CHECK 约束可以命名：CONSTRAINT chk_age CHECK (age >= 0)
2.3 [1]数据类型
01.数值类型
a.整数类型
TINYINT：1字节，范围 -128 到 127（有符号）或 0 到 255（无符号）
SMALLINT：2字节，范围 -32768 到 32767（有符号）或 0 到 65535（无符号）
MEDIUMINT：3字节，范围 -8388608 到 8388607（有符号）或 0 到 16777215（无符号）
INT 或 INTEGER：4字节，范围 -2147483648 到 2147483647（有符号）或 0 到 4294967295（无符号）
---------------------------------------------------------------------------------------------------------
BIGINT：8字节，范围 -9223372036854775808 到 9223372036854775807（有符号）
支持 UNSIGNED 修饰符表示无符号
支持 ZEROFILL 修饰符用零填充
支持 AUTO_INCREMENT 自动递增
---------------------------------------------------------------------------------------------------------
示例：CREATE TABLE t (id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, count BIGINT);
建议根据实际数据范围选择合适的类型
自增列必须定义为主键或唯一键的一部分
TiDB 的自增列是全局唯一的，但不保证连续
b.浮点类型
FLOAT：4字节单精度浮点数
DOUBLE 或 REAL：8字节双精度浮点数
DECIMAL 或 NUMERIC：定点数，精确存储
示例：price DECIMAL(10, 2) 表示总共10位，小数点后2位
---------------------------------------------------------------------------------------------------------
浮点数存在精度问题，不适合存储精确值（如金额）
DECIMAL 适合存储货币等需要精确计算的数据
DECIMAL(M, D) 中 M 是总位数，D 是小数位数
建议金融数据使用 DECIMAL 类型
c.位类型
BIT(M)：位字段类型，M 表示位数，范围 1 到 64
存储二进制位值
示例：flags BIT(8) 可以存储8个布尔标志
可以使用 b'value' 语法插入位值
---------------------------------------------------------------------------------------------------------
BIT 类型在查询时返回二进制值
可以使用 BIN()、HEX() 函数转换
适合存储标志位和状态位
注意与 TINYINT 的区别
02.字符串类型
a.字符类型
CHAR(M)：定长字符串，M 表示字符数，范围 0 到 255
VARCHAR(M)：变长字符串，M 表示最大字符数，范围 0 到 65535
CHAR 会用空格填充到指定长度，VARCHAR 不会
CHAR 适合存储长度固定的数据，VARCHAR 适合存储长度可变的数据
---------------------------------------------------------------------------------------------------------
示例：name VARCHAR(50), code CHAR(10)
字符数与字节数的关系取决于字符集
UTF-8 字符集中，一个汉字占3个字节
建议使用 VARCHAR 以节省存储空间
b.文本类型
TINYTEXT：最大长度 255 字节
TEXT：最大长度 65535 字节（约64KB）
MEDIUMTEXT：最大长度 16777215 字节（约16MB）
LONGTEXT：最大长度 4294967295 字节（约4GB）
---------------------------------------------------------------------------------------------------------
TEXT 类型不能有默认值
TEXT 类型不能作为主键
大文本建议存储在对象存储中，数据库只存储引用
TEXT 类型会影响查询性能，谨慎使用
c.二进制类型
BINARY(M)：定长二进制字符串
VARBINARY(M)：变长二进制字符串
TINYBLOB、BLOB、MEDIUMBLOB、LONGBLOB：二进制大对象
用于存储二进制数据，如图片、文件等
---------------------------------------------------------------------------------------------------------
BINARY 和 VARBINARY 类似于 CHAR 和 VARCHAR
BLOB 类型不受字符集影响
大文件建议存储在对象存储中
BLOB 类型会影响性能，谨慎使用
d.枚举和集合
ENUM：枚举类型，值必须是预定义的列表之一
SET：集合类型，值可以是预定义列表的零个或多个
示例：status ENUM('pending', 'approved', 'rejected')
示例：permissions SET('read', 'write', 'delete')
---------------------------------------------------------------------------------------------------------
ENUM 只能选择一个值，SET 可以选择多个值
ENUM 和 SET 在内部以整数存储
修改枚举值需要 ALTER TABLE
建议使用整数+映射表代替 ENUM 和 SET
03.日期时间类型
a.日期类型
DATE：日期，格式 'YYYY-MM-DD'，范围 '1000-01-01' 到 '9999-12-31'
存储年月日，不包含时间
占用3字节
示例：birthday DATE
---------------------------------------------------------------------------------------------------------
可以使用字符串或数字插入日期
支持多种日期格式
建议使用标准格式 'YYYY-MM-DD'
可以使用日期函数进行计算
b.时间类型
TIME：时间，格式 'HH:MM:SS'，范围 '-838:59:59' 到 '838:59:59'
存储时分秒，可以表示时间间隔
占用3字节
示例：duration TIME
---------------------------------------------------------------------------------------------------------
支持负值，可以表示时间差
可以包含微秒，格式 'HH:MM:SS.ffffff'
TIME 类型不包含日期信息
适合存储时间段或时长
c.日期时间类型
DATETIME：日期时间，格式 'YYYY-MM-DD HH:MM:SS'
范围 '1000-01-01 00:00:00' 到 '9999-12-31 23:59:59'
占用8字节
不受时区影响
---------------------------------------------------------------------------------------------------------
TIMESTAMP：时间戳，格式 'YYYY-MM-DD HH:MM:SS'
范围 '1970-01-01 00:00:01' UTC 到 '2038-01-19 03:14:07' UTC
占用4字节
受时区影响，存储时转换为 UTC
---------------------------------------------------------------------------------------------------------
DATETIME 适合存储固定时间点
TIMESTAMP 适合存储需要时区转换的时间
TIMESTAMP 支持自动更新：ON UPDATE CURRENT_TIMESTAMP
建议使用 DATETIME 或 BIGINT 存储时间戳
d.年份类型
YEAR：年份，格式 'YYYY'，范围 1901 到 2155
占用1字节
可以使用2位或4位数字表示
示例：birth_year YEAR
---------------------------------------------------------------------------------------------------------
2位数字会自动转换为4位
00-69 转换为 2000-2069
70-99 转换为 1970-1999
建议使用4位数字避免歧义
04.JSON类型
a.JSON基础
TiDB 支持 JSON 数据类型
可以存储 JSON 文档
支持 JSON 函数进行查询和操作
示例：CREATE TABLE t (id INT, data JSON);
---------------------------------------------------------------------------------------------------------
JSON 数据以二进制格式存储
支持自动验证 JSON 格式
可以存储复杂的嵌套结构
适合存储半结构化数据
b.JSON操作
插入 JSON：INSERT INTO t VALUES (1, '{"name": "Alice", "age": 30}');
查询 JSON：SELECT data->'$.name' FROM t;
更新 JSON：UPDATE t SET data = JSON_SET(data, '$.age', 31);
删除 JSON 字段：UPDATE t SET data = JSON_REMOVE(data, '$.age');
---------------------------------------------------------------------------------------------------------
使用 -> 或 ->> 操作符提取 JSON 值
-> 返回 JSON 类型，->> 返回字符串类型
支持路径表达式访问嵌套字段
可以使用 JSON 函数进行复杂操作
c.JSON索引
可以为 JSON 字段创建索引
使用生成列创建索引
示例：ALTER TABLE t ADD COLUMN name VARCHAR(50) AS (data->'$.name');
然后为生成列创建索引：CREATE INDEX idx_name ON t (name);
---------------------------------------------------------------------------------------------------------
生成列可以是虚拟列或存储列
虚拟列不占用存储空间，但每次查询时计算
存储列占用存储空间，但查询更快
建议为常用的 JSON 字段创建索引
2.4 [1]索引
01.索引类型
a.主键索引
PRIMARY KEY 自动创建主键索引
主键索引是唯一的且不能为 NULL
每个表只能有一个主键索引
主键索引是聚簇索引或非聚簇索引（取决于配置）
---------------------------------------------------------------------------------------------------------
TiDB 默认使用非聚簇索引
可以通过 CLUSTERED 关键字指定聚簇索引
聚簇索引将数据和索引存储在一起
非聚簇索引将数据和索引分开存储
b.唯一索引
UNIQUE INDEX 创建唯一索引
唯一索引保证列值的唯一性
NULL 值不参与唯一性检查
可以有多个唯一索引
---------------------------------------------------------------------------------------------------------
示例：CREATE UNIQUE INDEX idx_email ON users (email);
复合唯一索引：CREATE UNIQUE INDEX idx_name_email ON users (name, email);
唯一索引可以加速查询
违反唯一约束会导致插入或更新失败
c.普通索引
INDEX 或 KEY 创建普通索引
普通索引用于加速查询
可以有重复值
可以创建多列索引
---------------------------------------------------------------------------------------------------------
示例：CREATE INDEX idx_name ON users (name);
复合索引：CREATE INDEX idx_name_age ON users (name, age);
索引列的顺序很重要
遵循最左前缀原则
d.表达式索引
TiDB 支持表达式索引（从 v5.0 开始）
可以为表达式创建索引
示例：CREATE INDEX idx_lower_email ON users ((LOWER(email)));
表达式索引可以加速基于表达式的查询
---------------------------------------------------------------------------------------------------------
表达式必须用括号包围
表达式索引是虚拟生成列索引的简化形式
适合为函数计算结果创建索引
注意表达式的性能开销
02.索引操作
a.创建索引
CREATE INDEX 创建索引
可以在创建表时定义索引
也可以在表创建后添加索引
示例：CREATE INDEX idx_name ON users (name);
---------------------------------------------------------------------------------------------------------
ALTER TABLE users ADD INDEX idx_name (name);
创建索引可能需要较长时间
TiDB 支持在线 DDL，不阻塞读写
建议在低峰期创建索引
b.查看索引
SHOW INDEX FROM table_name：查看表的索引
SHOW CREATE TABLE table_name：查看表的创建语句（包含索引）
可以通过 information_schema.statistics 查询索引信息
EXPLAIN 查看查询是否使用索引
---------------------------------------------------------------------------------------------------------
索引信息包括索引名、列名、索引类型、唯一性等
Cardinality 表示索引的基数（不同值的数量）
Key_name 是索引名称
Seq_in_index 是列在索引中的位置
c.删除索引
DROP INDEX index_name ON table_name：删除索引
ALTER TABLE table_name DROP INDEX index_name：删除索引
不能删除主键索引（需要先删除主键约束）
删除索引不影响数据
---------------------------------------------------------------------------------------------------------
示例：DROP INDEX idx_name ON users;
删除索引可能影响查询性能
删除前确认索引未被使用
可以通过慢查询日志分析索引使用情况
d.重建索引
TiDB 不需要显式重建索引
索引会自动维护
如果需要重建，可以删除后重新创建
示例：DROP INDEX idx_name ON users; CREATE INDEX idx_name ON users (name);
---------------------------------------------------------------------------------------------------------
重建索引可能需要较长时间
重建过程中查询性能可能下降
建议在低峰期操作
TiDB 的在线 DDL 可以减少影响
03.索引设计
a.选择索引列
为经常出现在 WHERE、JOIN、ORDER BY、GROUP BY 子句中的列创建索引
选择性高的列更适合创建索引
避免为选择性低的列创建索引（如性别、状态等）
考虑列的数据类型和大小
---------------------------------------------------------------------------------------------------------
小的数据类型更适合创建索引
避免为 TEXT、BLOB 等大字段创建索引
可以为大字段的前缀创建索引
示例：CREATE INDEX idx_content ON articles (content(100));
b.复合索引
复合索引包含多个列
遵循最左前缀原则
索引列的顺序很重要
将选择性高的列放在前面
---------------------------------------------------------------------------------------------------------
示例：CREATE INDEX idx_name_age_city ON users (name, age, city);
可以使用 (name)、(name, age)、(name, age, city) 进行查询
不能使用 (age)、(city)、(age, city) 进行查询
根据查询模式设计复合索引
c.覆盖索引
覆盖索引包含查询所需的所有列
查询可以直接从索引获取数据，无需回表
可以大幅提升查询性能
示例：CREATE INDEX idx_name_email ON users (name, email);
---------------------------------------------------------------------------------------------------------
查询 SELECT name, email FROM users WHERE name = 'Alice' 可以使用覆盖索引
覆盖索引会增加索引大小
需要权衡索引大小和查询性能
适合高频查询的场景
d.索引维护
索引会自动维护，无需手动操作
写入操作会更新索引
过多的索引会影响写入性能
定期分析索引使用情况
---------------------------------------------------------------------------------------------------------
删除未使用的索引
避免创建冗余索引
监控索引大小和性能
使用 EXPLAIN 分析查询计划
2.5 [2]事务模型
01.事务基础
a.ACID特性
原子性（Atomicity）：事务中的所有操作要么全部成功，要么全部失败
一致性（Consistency）：事务执行前后，数据保持一致状态
隔离性（Isolation）：并发事务之间相互隔离，互不影响
持久性（Durability）：事务提交后，数据永久保存
---------------------------------------------------------------------------------------------------------
TiDB 完全支持 ACID 特性
通过 Percolator 模型实现分布式事务
使用 MVCC 实现事务隔离
通过 Raft 协议保证数据持久性
b.事务控制
BEGIN 或 START TRANSACTION：开始事务
COMMIT：提交事务
ROLLBACK：回滚事务
SAVEPOINT：设置保存点
---------------------------------------------------------------------------------------------------------
示例：BEGIN; INSERT INTO users VALUES (1, 'Alice'); COMMIT;
自动提交模式：SET autocommit = 1;
手动提交模式：SET autocommit = 0;
建议显式控制事务边界
c.事务隔离级别
TiDB 支持两种隔离级别
快照隔离（Snapshot Isolation，SI）：默认隔离级别
读已提交（Read Committed，RC）：从 v4.0 开始支持
可以通过 SET SESSION TRANSACTION ISOLATION LEVEL 设置
---------------------------------------------------------------------------------------------------------
快照隔离类似于可重复读（Repeatable Read）
读已提交避免脏读，但可能出现不可重复读
快照隔离性能更好，适合大多数场景
读已提交适合需要读取最新数据的场景
d.事务大小限制
TiDB 对事务大小有限制
单个事务的键值对数量限制为 300,000
单个事务的总大小限制为 100MB
超过限制会导致事务失败
---------------------------------------------------------------------------------------------------------
大事务会影响性能和稳定性
建议将大事务拆分为多个小事务
可以通过配置调整限制（不建议）
使用批量操作时注意事务大小
02.乐观事务
a.乐观事务原理
假设事务冲突较少
事务执行时不加锁
提交时检测冲突
如果有冲突，事务失败并回滚
---------------------------------------------------------------------------------------------------------
适合读多写少的场景
冲突较少时性能更好
冲突较多时需要频繁重试
TiDB 早期版本默认使用乐观事务
b.乐观事务流程
开始事务：获取 start_ts
执行操作：在本地缓存修改
提交事务：执行两阶段提交
Prewrite 阶段：检测冲突，写入锁和数据
---------------------------------------------------------------------------------------------------------
Commit 阶段：提交事务，清理锁
如果 Prewrite 失败，事务回滚
如果 Commit 失败，后台异步清理
使用 TSO 确定事务顺序
c.冲突处理
乐观事务在提交时检测冲突
冲突时返回错误，需要应用层重试
可以使用 SELECT FOR UPDATE 提前加锁
建议实现重试机制
---------------------------------------------------------------------------------------------------------
冲突错误：Write conflict
重试时需要重新开始事务
可以使用指数退避策略
监控冲突率，评估是否切换到悲观事务
d.使用场景
读多写少的场景
冲突较少的场景
对延迟敏感的场景
不希望长时间持有锁的场景
---------------------------------------------------------------------------------------------------------
示例：查询密集型应用
示例：读写比例 9:1 的场景
不适合高冲突场景
不适合长事务
03.悲观事务
a.悲观事务原理
假设事务冲突较多
事务执行时提前加锁
避免冲突，无需重试
锁会一直持有到事务结束
---------------------------------------------------------------------------------------------------------
适合写多读少的场景
冲突较多时性能更好
避免频繁重试
TiDB 从 v3.0 开始支持悲观事务
b.悲观事务流程
开始事务：获取 start_ts
执行操作：对涉及的行加锁
提交事务：执行两阶段提交
锁在事务提交后释放
---------------------------------------------------------------------------------------------------------
加锁操作会阻塞其他事务
锁超时时间可配置
支持死锁检测
自动处理死锁
c.锁机制
悲观锁在 DML 语句执行时加锁
SELECT FOR UPDATE：显式加锁
UPDATE、DELETE：自动加锁
INSERT：不加锁（使用乐观锁）
---------------------------------------------------------------------------------------------------------
锁的粒度是行级锁
锁存储在 TiKV 中
锁超时时间默认为 30 秒
可以通过 innodb_lock_wait_timeout 配置
d.使用场景
写多读少的场景
冲突较多的场景
需要避免重试的场景
需要严格顺序的场景
---------------------------------------------------------------------------------------------------------
示例：库存扣减
示例：账户余额更新
示例：订单状态更新
TiDB 从 v3.0.8 开始默认使用悲观事务
04.事务最佳实践
a.选择合适的事务模式
根据业务特点选择乐观或悲观事务
读多写少：乐观事务
写多读少：悲观事务
可以在会话级别切换
---------------------------------------------------------------------------------------------------------
SET SESSION tidb_txn_mode = 'optimistic';
SET SESSION tidb_txn_mode = 'pessimistic';
可以在事务级别切换
BEGIN OPTIMISTIC; 或 BEGIN PESSIMISTIC;
b.控制事务大小
避免大事务
将大事务拆分为多个小事务
单个事务不超过 300,000 个键值对
单个事务不超过 100MB
---------------------------------------------------------------------------------------------------------
大事务会占用大量内存
大事务会增加冲突概率
大事务会影响性能
使用批量操作时注意拆分
c.避免长事务
尽快提交或回滚事务
避免在事务中执行耗时操作
避免在事务中进行网络请求
避免在事务中等待用户输入
---------------------------------------------------------------------------------------------------------
长事务会持有锁
长事务会阻塞其他事务
长事务会影响 GC
长事务会增加冲突概率
d.错误处理
正确处理事务错误
实现重试机制
使用指数退避策略
设置最大重试次数
---------------------------------------------------------------------------------------------------------
捕获并处理 Write conflict 错误
捕获并处理锁超时错误
记录错误日志
监控事务失败率
2.6 [2]SQL语法
01.DDL语句
a.数据库DDL
CREATE DATABASE：创建数据库
ALTER DATABASE：修改数据库
DROP DATABASE：删除数据库
SHOW DATABASES：列出数据库
---------------------------------------------------------------------------------------------------------
示例：CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4;
示例：ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
示例：DROP DATABASE IF EXISTS mydb;
示例：SHOW DATABASES LIKE 'my%';
b.表DDL
CREATE TABLE：创建表
ALTER TABLE：修改表
DROP TABLE：删除表
TRUNCATE TABLE：清空表
---------------------------------------------------------------------------------------------------------
RENAME TABLE：重命名表
SHOW TABLES：列出表
SHOW CREATE TABLE：查看表创建语句
DESC 或 DESCRIBE：查看表结构
c.索引DDL
CREATE INDEX：创建索引
DROP INDEX：删除索引
ALTER TABLE ADD INDEX：添加索引
ALTER TABLE DROP INDEX：删除索引
---------------------------------------------------------------------------------------------------------
SHOW INDEX：查看索引
示例：CREATE INDEX idx_name ON users (name);
示例：DROP INDEX idx_name ON users;
示例：ALTER TABLE users ADD INDEX idx_email (email);
d.视图DDL
CREATE VIEW：创建视图
ALTER VIEW：修改视图
DROP VIEW：删除视图
SHOW CREATE VIEW：查看视图创建语句
---------------------------------------------------------------------------------------------------------
示例：CREATE VIEW v_users AS SELECT id, name FROM users WHERE active = 1;
示例：DROP VIEW IF EXISTS v_users;
视图是虚拟表，不存储数据
视图可以简化复杂查询
02.DML语句
a.INSERT语句
INSERT INTO：插入数据
支持插入单行或多行
支持从查询结果插入
支持 ON DUPLICATE KEY UPDATE
---------------------------------------------------------------------------------------------------------
示例：INSERT INTO users (name, email) VALUES ('Alice', '[email protected] ');
示例：INSERT INTO users (name, email) VALUES ('Bob', '[email protected] '), ('Charlie', '[email protected] ');
示例：INSERT INTO users (name, email) SELECT name, email FROM temp_users;
示例：INSERT INTO users (id, name) VALUES (1, 'Alice') ON DUPLICATE KEY UPDATE name = 'Alice';
b.UPDATE语句
UPDATE：更新数据
可以更新单行或多行
使用 WHERE 子句指定更新条件
可以更新多个列
---------------------------------------------------------------------------------------------------------
示例：UPDATE users SET email = '[email protected] ' WHERE id = 1;
示例：UPDATE users SET name = 'Bob', age = 30 WHERE id = 2;
示例：UPDATE users SET age = age + 1 WHERE city = 'Beijing';
不使用 WHERE 会更新所有行，需谨慎
c.DELETE语句
DELETE FROM：删除数据
使用 WHERE 子句指定删除条件
可以删除单行或多行
DELETE 不会重置自增列
---------------------------------------------------------------------------------------------------------
示例：DELETE FROM users WHERE id = 1;
示例：DELETE FROM users WHERE created_at < '2020-01-01';
不使用 WHERE 会删除所有行，需谨慎
TRUNCATE TABLE 比 DELETE 更快，但不能回滚
d.REPLACE语句
REPLACE INTO：替换数据
如果记录存在则删除后插入，否则直接插入
基于主键或唯一键判断记录是否存在
REPLACE 等价于 DELETE + INSERT
---------------------------------------------------------------------------------------------------------
示例：REPLACE INTO users (id, name, email) VALUES (1, 'Alice', '[email protected] ');
REPLACE 会触发删除和插入操作
如果有外键约束，可能导致级联删除
建议使用 INSERT ... ON DUPLICATE KEY UPDATE
03.DQL语句
a.SELECT基础
SELECT：查询数据
FROM：指定表
WHERE：过滤条件
ORDER BY：排序
---------------------------------------------------------------------------------------------------------
LIMIT：限制结果数量
OFFSET：跳过指定行数
示例：SELECT * FROM users WHERE age > 18 ORDER BY name LIMIT 10;
示例：SELECT id, name, email FROM users WHERE city = 'Beijing' ORDER BY created_at DESC LIMIT 10 OFFSET 20;
b.聚合查询
COUNT：计数
SUM：求和
AVG：平均值
MAX：最大值
---------------------------------------------------------------------------------------------------------
MIN：最小值
GROUP BY：分组
HAVING：分组过滤
示例：SELECT city, COUNT(*) as count FROM users GROUP BY city HAVING count > 10;
c.连接查询
INNER JOIN：内连接
LEFT JOIN：左连接
RIGHT JOIN：右连接
CROSS JOIN：交叉连接
---------------------------------------------------------------------------------------------------------
示例：SELECT u.name, o.order_id FROM users u INNER JOIN orders o ON u.id = o.user_id;
示例：SELECT u.name, o.order_id FROM users u LEFT JOIN orders o ON u.id = o.user_id;
连接条件使用 ON 子句
可以连接多个表
d.子查询
子查询可以出现在 SELECT、FROM、WHERE 子句中
标量子查询：返回单个值
行子查询：返回单行
表子查询：返回多行多列
---------------------------------------------------------------------------------------------------------
示例：SELECT name FROM users WHERE id IN (SELECT user_id FROM orders WHERE amount > 1000);
示例：SELECT name, (SELECT COUNT(*) FROM orders WHERE user_id = users.id) as order_count FROM users;
子查询可以嵌套
注意子查询的性能
04.DCL语句
a.用户管理
CREATE USER：创建用户
ALTER USER：修改用户
DROP USER：删除用户
RENAME USER：重命名用户
---------------------------------------------------------------------------------------------------------
示例：CREATE USER 'alice'@'%' IDENTIFIED BY 'password';
示例：ALTER USER 'alice'@'%' IDENTIFIED BY 'newpassword';
示例：DROP USER 'alice'@'%';
示例：RENAME USER 'alice'@'%' TO 'bob'@'%';
b.权限管理
GRANT：授予权限
REVOKE：撤销权限
SHOW GRANTS：查看权限
FLUSH PRIVILEGES：刷新权限
---------------------------------------------------------------------------------------------------------
示例：GRANT SELECT, INSERT ON mydb.* TO 'alice'@'%';
示例：GRANT ALL PRIVILEGES ON *.* TO 'admin'@'%';
示例：REVOKE INSERT ON mydb.* FROM 'alice'@'%';
示例：SHOW GRANTS FOR 'alice'@'%';
c.角色管理
CREATE ROLE：创建角色
DROP ROLE：删除角色
GRANT role TO user：将角色授予用户
SET ROLE：激活角色
---------------------------------------------------------------------------------------------------------
示例：CREATE ROLE 'app_read';
示例：GRANT SELECT ON mydb.* TO 'app_read';
示例：GRANT 'app_read' TO 'alice'@'%';
示例：SET ROLE 'app_read';
d.权限级别
全局权限：*.* 表示所有数据库
数据库权限：dbname.* 表示指定数据库
表权限：dbname.tablename 表示指定表
列权限：可以授予特定列的权限
---------------------------------------------------------------------------------------------------------
权限包括：SELECT、INSERT、UPDATE、DELETE、CREATE、DROP、ALTER、INDEX 等
建议遵循最小权限原则
定期审查用户权限
避免使用 root 用户进行日常操作
2.7 [2]附：与MySQL兼容性
01.兼容性说明
a.协议兼容
TiDB 高度兼容 MySQL 5.7 协议
支持 MySQL 客户端和驱动程序
可以使用 MySQL 命令行工具连接 TiDB
大部分 MySQL 应用可以无缝迁移
---------------------------------------------------------------------------------------------------------
兼容 MySQL 的认证机制
支持 MySQL 的字符集和排序规则
兼容 MySQL 的 SQL 语法
支持 MySQL 的函数和操作符
b.语法兼容
支持大部分 MySQL SQL 语法
支持 DDL、DML、DQL、DCL 语句
支持事务控制语句
支持存储过程和函数（部分支持）
---------------------------------------------------------------------------------------------------------
支持触发器（部分支持）
支持视图
支持 CTE（公用表表达式）
支持窗口函数
c.功能兼容
支持 ACID 事务
支持多种数据类型
支持索引（主键、唯一、普通、表达式索引）
支持外键（语法兼容，但不强制约束）
---------------------------------------------------------------------------------------------------------
支持分区表
支持 JSON 数据类型
支持字符集和排序规则
支持权限管理
d.工具兼容
兼容 MySQL 客户端工具
兼容 MySQL 驱动程序（JDBC、Python、Go 等）
兼容 ORM 框架（Hibernate、MyBatis、Django ORM 等）
兼容数据库管理工具（Navicat、DBeaver、MySQL Workbench 等）
---------------------------------------------------------------------------------------------------------
兼容备份恢复工具（mysqldump 等）
兼容数据迁移工具
提供专用工具（TiUP、BR、DM、TiCDC 等）
支持 Prometheus 和 Grafana 监控
02.差异对比
a.不支持的特性
不支持外键约束（语法兼容，但不强制）
不支持全文索引
不支持空间索引和空间函数
不支持 XA 事务
---------------------------------------------------------------------------------------------------------
不支持 SAVEPOINT（部分支持）
不支持自定义函数（UDF）
不支持事件调度器（Event Scheduler）
不支持部分存储引擎特定功能
b.行为差异
自增列是全局唯一的，但不保证连续
AUTO_INCREMENT 的行为与 MySQL 不同
事务隔离级别只支持 SI 和 RC
默认隔离级别是快照隔离（SI）
---------------------------------------------------------------------------------------------------------
TRUNCATE TABLE 是 DDL 操作，会提交当前事务
部分 DDL 操作的行为与 MySQL 不同
锁机制与 MySQL 不同
MVCC 实现与 MySQL 不同
c.性能差异
单机性能略低于 MySQL
分布式事务有额外开销
小数据量场景性能优势不明显
大数据量和高并发场景性能更好
---------------------------------------------------------------------------------------------------------
支持水平扩展，性能可线性提升
OLAP 查询性能优于 MySQL（通过 TiFlash）
写入性能受分布式事务影响
读取性能可通过扩展 TiDB Server 提升
d.限制差异
单个事务大小限制为 100MB
单个事务键值对数量限制为 300,000
单个 Region 大小限制为 96MB（可配置）
表名、列名长度限制与 MySQL 相同
---------------------------------------------------------------------------------------------------------
不支持超大表（单表超过 10TB 需要分区）
不支持超大事务
部分 SQL 语句有长度限制
部分功能有性能限制
03.迁移注意事项
a.应用改造
检查应用是否使用不支持的特性
检查外键约束的使用
检查全文索引的使用
检查存储过程和触发器的使用
---------------------------------------------------------------------------------------------------------
修改自增列的使用方式
调整事务大小和事务逻辑
优化 SQL 语句
添加重试机制处理事务冲突
b.数据迁移
使用 DM 工具进行在线迁移
使用 TiDB Lightning 进行离线迁移
使用 mysqldump 导出导入
使用 Dumpling 和 TiDB Lightning 组合
---------------------------------------------------------------------------------------------------------
迁移前备份数据
在测试环境验证迁移
制定回滚方案
监控迁移过程
c.性能调优
根据业务特点选择事务模式
优化索引设计
调整事务大小
使用 TiFlash 加速 OLAP 查询
---------------------------------------------------------------------------------------------------------
监控慢查询
使用 EXPLAIN 分析查询计划
调整配置参数
扩展集群规模
d.运维调整
学习 TiDB 的运维工具
配置监控和告警
制定备份恢复策略
制定扩缩容计划
---------------------------------------------------------------------------------------------------------
了解 TiDB 的架构和原理
掌握故障排查方法
建立运维流程和规范
培训运维团队
3 TiDB进阶
3.1 [1]分布式事务
01.Percolator模型
a.模型概述
Percolator 是 Google 提出的分布式事务模型
基于 Bigtable 构建，TiDB 基于 TiKV 实现
使用两阶段提交（2PC）协议
通过 MVCC 实现事务隔离
---------------------------------------------------------------------------------------------------------
支持跨节点的 ACID 事务
使用 TSO 保证事务顺序
支持快照隔离级别
适合大规模分布式系统
b.核心概念
Primary Key：事务的主键，协调事务状态
Secondary Keys：事务的其他键，依赖主键状态
Lock：事务锁，保护数据不被其他事务修改
Write：写入记录，表示数据的版本
---------------------------------------------------------------------------------------------------------
Data：实际数据
start_ts：事务开始时间戳
commit_ts：事务提交时间戳
TSO：全局时间戳服务
02.两阶段提交
a.Prewrite阶段
在所有涉及的 Region 上写入锁和数据
选择一个键作为 Primary Key
其他键作为 Secondary Keys
Primary Key 的锁包含事务的所有信息
---------------------------------------------------------------------------------------------------------
Secondary Keys 的锁指向 Primary Key
如果任何一个键的 Prewrite 失败，事务回滚
Prewrite 成功后，数据对其他事务不可见
锁包含 start_ts 和 Primary Key 信息
b.Commit阶段
提交 Primary Key
Primary Key 提交成功后，事务即为成功
异步提交 Secondary Keys
清理锁
---------------------------------------------------------------------------------------------------------
Commit 阶段只修改 Primary Key 的锁为 Write 记录
Secondary Keys 的提交可以异步进行
如果 Commit 失败，后台会异步清理
使用 commit_ts 作为数据的版本号
c.冲突检测
Prewrite 阶段检测写写冲突
如果发现其他事务的锁，等待或回滚
如果发现更新的 Write 记录，回滚
使用 start_ts 和 commit_ts 判断冲突
---------------------------------------------------------------------------------------------------------
乐观事务在 Prewrite 时检测冲突
悲观事务在 DML 执行时加锁
冲突检测基于 MVCC 版本
支持死锁检测
d.事务清理
事务提交后，异步清理锁
如果事务失败，回滚并清理锁
使用 GC 清理旧版本数据
TTL 机制处理僵尸锁
---------------------------------------------------------------------------------------------------------
锁超时后自动清理
GC 定期清理旧版本
保留最近的版本用于 MVCC
清理过程对业务透明
3.2 [1]HTAP能力
01.HTAP概述
a.HTAP定义
HTAP（Hybrid Transactional/Analytical Processing）：混合事务分析处理
同时支持 OLTP 和 OLAP 场景
一套系统解决事务处理和实时分析需求
避免维护多套系统的复杂性
---------------------------------------------------------------------------------------------------------
TiDB 原生支持 HTAP
通过 TiKV（行存）和 TiFlash（列存）实现
实时数据同步，无需 ETL
统一 SQL 接口
b.HTAP优势
降低系统复杂度：无需维护多套系统
降低数据延迟：实时同步，无需 ETL
保证数据一致性：单一数据源
降低成本：减少硬件和运维成本
---------------------------------------------------------------------------------------------------------
简化应用开发：统一 SQL 接口
提升开发效率：无需数据同步逻辑
支持混合负载：事务和分析互不影响
灵活扩展：独立扩展 OLTP 和 OLAP 能力
c.HTAP架构
TiKV：行存引擎，优化 OLTP 性能
TiFlash：列存引擎，优化 OLAP 性能
实时同步：通过 Raft Learner 协议
智能路由：查询优化器自动选择引擎
---------------------------------------------------------------------------------------------------------
TiKV 和 TiFlash 数据实时同步
同步延迟通常在秒级
支持混合查询
支持 MPP 架构
02.TiKV与TiFlash
a.TiKV行存
按行存储数据
适合点查询和事务处理
支持高并发写入
优化单行读写性能
---------------------------------------------------------------------------------------------------------
基于 RocksDB 构建
使用 LSM-Tree 数据结构
支持 MVCC
支持分布式事务
b.TiFlash列存
按列存储数据
适合扫描和聚合查询
支持向量化执行
优化分析查询性能
---------------------------------------------------------------------------------------------------------
通过 Raft Learner 同步数据
实时同步，延迟秒级
支持数据压缩
支持并行查询
c.数据同步
TiFlash 通过 Raft Learner 从 TiKV 同步数据
不参与 Raft 投票，不影响 TiKV 性能
支持增量同步，只同步变更数据
自动将行存数据转换为列存格式
---------------------------------------------------------------------------------------------------------
同步过程对业务透明
支持选择性同步，只同步需要的表
保证数据一致性
同步延迟可监控
d.查询路由
查询优化器根据查询类型选择存储引擎
点查询和事务使用 TiKV
扫描和聚合查询使用 TiFlash
可以通过 Hint 强制指定引擎
---------------------------------------------------------------------------------------------------------
优化器基于成本模型选择
考虑数据分布、索引、统计信息
支持混合查询 TiKV 和 TiFlash
提供 EXPLAIN 分析查询计划
3.3 [2]TiFlash列存引擎
01.TiFlash架构
a.存储架构
列式存储格式
使用 Delta Tree 存储引擎
支持数据压缩
支持向量化执行
---------------------------------------------------------------------------------------------------------
数据按列组织
每列独立存储和压缩
支持多种压缩算法
优化 IO 性能
b.计算架构
支持 MPP（Massively Parallel Processing）
分布式并行计算
向量化执行引擎
支持算子下推
---------------------------------------------------------------------------------------------------------
充分利用多核 CPU
支持 SIMD 指令加速
支持并行聚合和 JOIN
支持分布式 JOIN
c.同步机制
通过 Raft Learner 协议同步
不参与 Raft 投票
实时增量同步
自动数据转换
---------------------------------------------------------------------------------------------------------
同步延迟秒级
支持断点续传
自动故障恢复
保证数据一致性
d.副本管理
TiFlash 副本独立于 TiKV 副本
可以配置 TiFlash 副本数
副本分布在不同的 TiFlash 节点
支持副本调度和负载均衡
---------------------------------------------------------------------------------------------------------
副本数可动态调整
支持在线添加删除副本
副本故障自动恢复
副本数据自动同步
02.TiFlash使用
a.创建TiFlash副本
使用 ALTER TABLE 添加 TiFlash 副本
示例：ALTER TABLE users SET TIFLASH REPLICA 1;
指定副本数，通常为 1 或 2
副本创建后自动同步数据
---------------------------------------------------------------------------------------------------------
查看副本状态：SELECT * FROM information_schema.tiflash_replica;
等待副本同步完成
同步时间取决于数据量
同步过程不影响业务
b.查询TiFlash
查询优化器自动选择 TiFlash
可以使用 Hint 强制使用 TiFlash
示例：SELECT /*+ READ_FROM_STORAGE(TIFLASH[users]) */ * FROM users;
EXPLAIN 查看是否使用 TiFlash
---------------------------------------------------------------------------------------------------------
TiFlash 适合扫描和聚合查询
点查询仍然使用 TiKV
混合查询可能同时使用 TiKV 和 TiFlash
监控 TiFlash 查询性能
c.删除TiFlash副本
使用 ALTER TABLE 删除 TiFlash 副本
示例：ALTER TABLE users SET TIFLASH REPLICA 0;
删除副本不影响 TiKV 数据
删除后查询自动路由到 TiKV
---------------------------------------------------------------------------------------------------------
删除副本释放存储空间
删除过程对业务透明
可以随时重新创建副本
建议在低峰期删除
d.监控TiFlash
监控副本同步状态
监控查询性能
监控资源使用情况
监控错误和告警
---------------------------------------------------------------------------------------------------------
使用 Grafana 查看监控指标
关注同步延迟
关注查询响应时间
关注 CPU 和内存使用率
03.MPP架构
a.MPP概述
MPP（Massively Parallel Processing）：大规模并行处理
TiDB 从 5.0 开始支持 MPP
分布式并行计算
大幅提升 OLAP 性能
---------------------------------------------------------------------------------------------------------
将计算任务分发到多个 TiFlash 节点
并行执行，充分利用集群资源
支持分布式 JOIN 和聚合
OLAP 性能提升 10 倍以上
b.MPP执行
查询优化器生成 MPP 执行计划
将计算任务分发到 TiFlash 节点
各节点并行执行
汇总结果返回给 TiDB Server
---------------------------------------------------------------------------------------------------------
支持多阶段执行
支持数据 Shuffle
支持分布式 JOIN
支持分布式聚合
c.MPP优化
选择合适的 JOIN 算法
优化数据分布
调整并行度
使用合适的聚合策略
---------------------------------------------------------------------------------------------------------
监控 MPP 查询性能
使用 EXPLAIN 分析执行计划
调整配置参数
扩展 TiFlash 节点
d.MPP限制
只支持 TiFlash 引擎
不支持所有 SQL 语句
部分函数不支持
需要足够的 TiFlash 节点
---------------------------------------------------------------------------------------------------------
查询优化器自动判断是否使用 MPP
可以通过配置启用或禁用 MPP
监控 MPP 使用情况
根据业务需求调整
3.4 [2]分区表
01.分区类型
a.范围分区
RANGE 分区：按范围分区
适合时间序列数据
示例：PARTITION BY RANGE (YEAR(created_at))
支持按表达式分区
---------------------------------------------------------------------------------------------------------
示例：CREATE TABLE orders (id INT, created_at DATE) PARTITION BY RANGE (YEAR(created_at)) (
PARTITION p2020 VALUES LESS THAN (2021),
PARTITION p2021 VALUES LESS THAN (2022),
PARTITION p2022 VALUES LESS THAN (2023)
);
可以动态添加删除分区
适合历史数据归档
提升查询和维护性能
b.列表分区
LIST 分区：按列表分区
适合离散值分区
示例：PARTITION BY LIST (region)
支持多个值
---------------------------------------------------------------------------------------------------------
示例：CREATE TABLE users (id INT, region VARCHAR(20)) PARTITION BY LIST (region) (
PARTITION p_north VALUES IN ('Beijing', 'Tianjin'),
PARTITION p_south VALUES IN ('Shanghai', 'Shenzhen')
);
适合按类别分区
便于数据管理
提升查询性能
c.哈希分区
HASH 分区：按哈希值分区
数据均匀分布
示例：PARTITION BY HASH (id)
指定分区数量
---------------------------------------------------------------------------------------------------------
示例：CREATE TABLE users (id INT, name VARCHAR(50)) PARTITION BY HASH (id) PARTITIONS 4;
适合数据均匀分布
避免热点问题
简化分区管理
d.列分区
COLUMNS 分区：支持多列分区
可以使用多个列作为分区键
支持 RANGE COLUMNS 和 LIST COLUMNS
更灵活的分区策略
---------------------------------------------------------------------------------------------------------
示例：PARTITION BY RANGE COLUMNS (year, month)
支持非整数类型
支持多列组合
适合复杂的分区需求
02.分区操作
a.创建分区表
在 CREATE TABLE 时指定分区
选择合适的分区类型
定义分区规则
指定分区数量或范围
---------------------------------------------------------------------------------------------------------
考虑数据分布和查询模式
避免过多或过少的分区
建议分区数量在 100 以内
定期评估分区策略
b.添加分区
ALTER TABLE ADD PARTITION：添加分区
适用于 RANGE 和 LIST 分区
示例：ALTER TABLE orders ADD PARTITION (PARTITION p2023 VALUES LESS THAN (2024));
添加分区不影响现有数据
---------------------------------------------------------------------------------------------------------
HASH 分区不支持添加分区
添加分区后自动路由新数据
可以批量添加多个分区
建议在低峰期操作
c.删除分区
ALTER TABLE DROP PARTITION：删除分区
删除分区会删除分区中的数据
示例：ALTER TABLE orders DROP PARTITION p2020;
删除操作不可恢复
---------------------------------------------------------------------------------------------------------
删除前备份数据
HASH 分区不支持删除分区
可以批量删除多个分区
适合归档历史数据
d.重组分区
ALTER TABLE REORGANIZE PARTITION：重组分区
合并或拆分分区
适用于 RANGE 和 LIST 分区
示例：ALTER TABLE orders REORGANIZE PARTITION p2020, p2021 INTO (PARTITION p2020_2021 VALUES LESS THAN (2022));
---------------------------------------------------------------------------------------------------------
重组分区会移动数据
操作时间取决于数据量
建议在低峰期操作
HASH 分区不支持重组
03.分区优化
a.分区裁剪
查询时自动过滤不相关的分区
只扫描相关分区，提升性能
WHERE 条件包含分区键时生效
EXPLAIN 查看分区裁剪情况
---------------------------------------------------------------------------------------------------------
示例：SELECT * FROM orders WHERE created_at >= '2022-01-01' AND created_at < '2023-01-01';
只扫描 p2022 分区
大幅减少扫描数据量
提升查询性能
b.分区索引
每个分区有独立的索引
索引大小更小，查询更快
支持全局索引和局部索引
建议为分区键创建索引
---------------------------------------------------------------------------------------------------------
全局索引跨所有分区
局部索引只在单个分区内
分区表的索引维护成本更低
注意索引大小和数量
c.分区统计信息
每个分区有独立的统计信息
定期更新统计信息
使用 ANALYZE TABLE 收集
统计信息影响查询计划
---------------------------------------------------------------------------------------------------------
示例：ANALYZE TABLE orders PARTITION p2022;
可以只分析特定分区
建议定期分析
监控统计信息准确性
d.分区维护
定期检查分区状态
及时添加新分区
归档或删除旧分区
监控分区大小和数量
---------------------------------------------------------------------------------------------------------
自动化分区管理
使用脚本定期维护
监控分区使用情况
优化分区策略
3.5 [2]读写分离
01.Follower Read
a.Follower Read概述
TiKV 支持从 Follower 读取数据
分担 Leader 的读压力
提升读性能
降低 Leader 负载
---------------------------------------------------------------------------------------------------------
Follower Read 读取的是 Follower 副本的数据
可能有轻微延迟
适合对一致性要求不高的场景
可以显著提升读吞吐量
b.Follower Read配置
通过配置启用 Follower Read
可以在会话级别或全局级别设置
示例：SET SESSION tidb_replica_read = 'follower';
支持多种读取策略
---------------------------------------------------------------------------------------------------------
leader：只从 Leader 读取（默认）
follower：优先从 Follower 读取
leader-and-follower：Leader 和 Follower 都可以读取
closest-replicas：从最近的副本读取
c.一致性保证
Follower Read 可能读到稍旧的数据
延迟通常在毫秒级
可以通过 TSO 保证一致性
适合读多写少的场景
---------------------------------------------------------------------------------------------------------
强一致性读取使用 Leader Read
最终一致性读取使用 Follower Read
根据业务需求选择
监控读取延迟
d.使用场景
读多写少的场景
对一致性要求不高的场景
需要提升读性能的场景
需要降低 Leader 负载的场景
---------------------------------------------------------------------------------------------------------
示例：报表查询
示例：数据分析
示例：缓存预热
不适合强一致性要求的场景
02.读写分离架构
a.架构设计
TiDB Server 负责 SQL 处理
TiKV 负责数据存储
读请求可以路由到不同的副本
写请求必须路由到 Leader
---------------------------------------------------------------------------------------------------------
通过负载均衡器分发请求
读写分离对应用透明
可以独立扩展读能力
提升系统整体性能
b.负载均衡
使用负载均衡器分发请求
支持多种负载均衡策略
轮询、最少连接、IP 哈希等
监控各节点负载
---------------------------------------------------------------------------------------------------------
TiDB Server 无状态，易于负载均衡
可以使用 HAProxy、Nginx 等
支持健康检查
自动剔除故障节点
c.连接池
使用连接池管理数据库连接
减少连接开销
提升性能
支持连接复用
---------------------------------------------------------------------------------------------------------
配置合适的连接池大小
监控连接池使用情况
避免连接泄漏
定期回收空闲连接
d.应用层分离
应用层区分读写请求
写请求路由到主库
读请求路由到从库
需要应用层改造
---------------------------------------------------------------------------------------------------------
使用不同的数据源
配置读写数据源
实现读写路由逻辑
处理数据延迟
3.6 [2]性能优化
01.查询优化
a.索引优化
为常用查询创建索引
选择合适的索引类型
避免冗余索引
定期分析索引使用情况
---------------------------------------------------------------------------------------------------------
使用 EXPLAIN 分析查询计划
检查是否使用索引
优化索引设计
删除未使用的索引
b.SQL优化
避免全表扫描
使用合适的 JOIN 类型
优化子查询
避免使用 SELECT *
---------------------------------------------------------------------------------------------------------
使用 LIMIT 限制结果集
避免在 WHERE 中使用函数
使用 UNION ALL 代替 UNION
批量操作代替逐条操作
c.统计信息
定期收集统计信息
使用 ANALYZE TABLE 更新
统计信息影响查询计划
监控统计信息准确性
---------------------------------------------------------------------------------------------------------
示例：ANALYZE TABLE users;
可以自动收集统计信息
配置自动收集策略
关注统计信息过期
d.执行计划
使用 EXPLAIN 查看执行计划
分析扫描行数、索引使用等
优化执行计划
使用 Hint 强制执行计划
---------------------------------------------------------------------------------------------------------
示例：EXPLAIN SELECT * FROM users WHERE id = 1;
关注 type、rows、Extra 等字段
避免全表扫描（type = ALL）
优先使用索引扫描
02.事务优化
a.选择事务模式
根据业务特点选择乐观或悲观事务
读多写少使用乐观事务
写多读少使用悲观事务
可以在会话级别切换
---------------------------------------------------------------------------------------------------------
监控事务冲突率
评估事务模式效果
根据业务调整
避免频繁切换
b.控制事务大小
避免大事务
单个事务不超过 100MB
单个事务不超过 300,000 个键值对
将大事务拆分为多个小事务
---------------------------------------------------------------------------------------------------------
批量操作时注意拆分
监控事务大小
优化事务逻辑
使用批量接口
c.减少事务冲突
避免热点数据
使用合理的分片策略
错峰处理
使用队列缓冲
---------------------------------------------------------------------------------------------------------
监控冲突率
分析冲突原因
优化业务逻辑
使用悲观事务避免冲突
d.事务超时
配置合适的超时时间
避免长事务
及时提交或回滚
监控事务执行时间
---------------------------------------------------------------------------------------------------------
innodb_lock_wait_timeout：锁等待超时
tidb_gc_life_time：GC 保留时间
根据业务调整
避免超时导致失败
03.系统优化
a.配置优化
调整 TiDB Server 配置
调整 TiKV 配置
调整 PD 配置
根据硬件和业务调整
---------------------------------------------------------------------------------------------------------
内存配置：tidb_mem_quota_query
并发配置：tidb_executor_concurrency
缓存配置：tikv_client_cache_size
监控配置效果
b.硬件优化
使用 SSD 存储
增加内存
使用高性能网络
使用多核 CPU
---------------------------------------------------------------------------------------------------------
TiKV 对 IO 性能要求高
TiDB Server 对 CPU 和内存要求高
PD 对网络延迟敏感
根据组件特点配置硬件
c.集群扩展
水平扩展 TiDB Server
水平扩展 TiKV
水平扩展 TiFlash
根据瓶颈扩展
---------------------------------------------------------------------------------------------------------
监控各组件负载
识别瓶颈
针对性扩展
评估扩展效果
d.监控优化
使用 Prometheus 和 Grafana
监控关键指标
设置告警
定期分析
---------------------------------------------------------------------------------------------------------
监控 QPS、延迟、错误率
监控资源使用情况
监控慢查询
根据监控数据优化
4 TiDB高级
4.1 [1]集群管理
01.TiUP工具
a.TiUP概述
TiUP 是 TiDB 的官方部署和运维工具
支持集群的部署、启动、停止、销毁等操作
支持集群的扩缩容、升级、备份恢复等
提供命令行和配置文件两种方式
---------------------------------------------------------------------------------------------------------
安装 TiUP：curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
更新 TiUP：tiup update --self && tiup update cluster
查看版本：tiup --version
查看帮助：tiup cluster help
b.集群部署
使用 TiUP 部署集群
准备拓扑配置文件
执行部署命令
启动集群
---------------------------------------------------------------------------------------------------------
示例：tiup cluster deploy my-cluster v7.5.0 topology.yaml --user root
检查配置：tiup cluster check topology.yaml
启动集群：tiup cluster start my-cluster
查看集群状态：tiup cluster display my-cluster
c.集群操作
启动集群：tiup cluster start cluster-name
停止集群：tiup cluster stop cluster-name
重启集群：tiup cluster restart cluster-name
销毁集群：tiup cluster destroy cluster-name
---------------------------------------------------------------------------------------------------------
查看集群列表：tiup cluster list
查看集群状态：tiup cluster display cluster-name
查看日志：tiup cluster logs cluster-name
执行命令：tiup cluster exec cluster-name --command "ls -l"
d.配置管理
查看配置：tiup cluster edit-config cluster-name
修改配置：编辑配置文件后重新加载
重新加载配置：tiup cluster reload cluster-name
配置生效无需重启
---------------------------------------------------------------------------------------------------------
配置文件格式为 YAML
支持组件级别和实例级别配置
修改配置前备份
验证配置正确性
02.集群监控
a.Prometheus监控
TiDB 使用 Prometheus 收集监控指标
自动部署 Prometheus 和 Grafana
提供丰富的监控面板
支持自定义监控指标
---------------------------------------------------------------------------------------------------------
访问 Grafana：http://monitoring-host:3000
默认用户名密码：admin/admin
查看各组件监控面板
配置告警规则
b.关键指标
QPS：每秒查询数
延迟：查询响应时间（P99、P95、平均值）
错误率：失败请求比例
资源使用：CPU、内存、磁盘、网络
---------------------------------------------------------------------------------------------------------
TiDB Server：连接数、SQL 执行时间、慢查询
TiKV：Region 数量、Leader 数量、IO 吞吐量
PD：TSO 分配速度、调度任务数量
监控趋势和异常
c.告警配置
配置告警规则
设置告警阈值
配置告警通知渠道
定期检查告警
---------------------------------------------------------------------------------------------------------
支持邮件、钉钉、企业微信等通知方式
配置告警分级
避免告警风暴
及时处理告警
d.日志管理
TiDB 组件日志位置
TiDB Server：{deploy_dir}/log
TiKV：{deploy_dir}/log
PD：{deploy_dir}/log
---------------------------------------------------------------------------------------------------------
配置日志级别
定期清理日志
使用日志分析工具
关注错误和警告日志
4.2 [1]扩缩容
01.扩容操作
a.扩容TiDB Server
准备新节点
编辑拓扑配置文件，添加新节点
执行扩容命令：tiup cluster scale-out cluster-name scale-out.yaml
验证扩容结果
---------------------------------------------------------------------------------------------------------
TiDB Server 无状态，扩容快速
扩容后自动加入集群
更新负载均衡器配置
监控新节点状态
b.扩容TiKV
准备新节点
编辑拓扑配置文件，添加新节点
执行扩容命令
等待数据均衡完成
---------------------------------------------------------------------------------------------------------
TiKV 扩容需要数据迁移
PD 自动调度 Region 到新节点
扩容时间取决于数据量
监控数据均衡进度
c.扩容PD
准备新节点
编辑拓扑配置文件，添加新节点
执行扩容命令
验证 PD 集群状态
---------------------------------------------------------------------------------------------------------
PD 扩容需要加入 Raft 集群
建议 PD 节点数为奇数（3或5）
扩容后验证 Leader 选举
监控 PD 集群健康状态
d.扩容TiFlash
准备新节点
编辑拓扑配置文件，添加新节点
执行扩容命令
等待副本同步完成
---------------------------------------------------------------------------------------------------------
TiFlash 扩容需要数据同步
同步时间取决于数据量
监控同步进度
验证副本分布
02.缩容操作
a.缩容TiDB Server
确定要下线的节点
执行缩容命令：tiup cluster scale-in cluster-name --node ip:port
验证缩容结果
更新负载均衡器配置
---------------------------------------------------------------------------------------------------------
TiDB Server 无状态，缩容快速
确保有足够的 TiDB Server 节点
避免影响业务
监控剩余节点负载
b.缩容TiKV
确定要下线的节点
执行缩容命令
等待数据迁移完成
验证缩容结果
---------------------------------------------------------------------------------------------------------
TiKV 缩容需要数据迁移
PD 自动将 Region 迁移到其他节点
缩容时间取决于数据量
确保剩余节点有足够容量
c.缩容PD
确定要下线的节点
执行缩容命令
验证 PD 集群状态
确保 PD 集群正常
---------------------------------------------------------------------------------------------------------
PD 缩容需要从 Raft 集群中移除
建议保留至少 3 个 PD 节点
避免下线 Leader 节点
监控 PD 集群健康状态
d.缩容TiFlash
确定要下线的节点
执行缩容命令
等待副本迁移完成
验证缩容结果
---------------------------------------------------------------------------------------------------------
TiFlash 缩容需要副本迁移
确保剩余节点有足够容量
监控副本分布
验证查询正常
03.滚动升级
a.升级准备
阅读版本发布说明
了解不兼容变更
在测试环境验证
备份数据
---------------------------------------------------------------------------------------------------------
准备回滚方案
选择合适的升级时间
通知相关人员
准备应急预案
b.升级流程
使用 TiUP 执行升级
命令：tiup cluster upgrade cluster-name v7.5.0
滚动升级，逐个节点升级
升级过程对业务影响最小
---------------------------------------------------------------------------------------------------------
升级顺序：PD → TiFlash → TiKV → TiDB Server
每个组件升级完成后验证
监控升级过程
遇到问题及时回滚
c.升级验证
检查集群状态
验证各组件版本
执行功能测试
监控性能指标
---------------------------------------------------------------------------------------------------------
查看版本：tiup cluster display cluster-name
检查日志是否有错误
执行业务测试
监控一段时间确保稳定
d.回滚操作
如果升级失败，执行回滚
使用备份恢复数据
回滚到原版本
分析失败原因
---------------------------------------------------------------------------------------------------------
回滚命令：tiup cluster upgrade cluster-name v7.1.0
验证回滚结果
修复问题后重新升级
记录升级经验
4.3 [2]备份恢复
01.BR工具
a.BR概述
BR（Backup & Restore）是 TiDB 的备份恢复工具
支持全量备份和增量备份
支持快速备份和恢复
支持备份到本地或云存储
---------------------------------------------------------------------------------------------------------
安装 BR：tiup install br
查看版本：tiup br --version
查看帮助：tiup br help
支持 S3、GCS、Azure Blob 等云存储
b.全量备份
备份整个集群的数据
使用 BR 执行备份
指定备份目录
监控备份进度
---------------------------------------------------------------------------------------------------------
示例：tiup br backup full --pd "127.0.0.1:2379" --storage "local:///backup"
备份到 S3：--storage "s3://bucket/path"
备份时间取决于数据量
备份过程不影响业务
c.增量备份
备份自上次备份以来的变更数据
基于 TiCDC 实现
减少备份时间和存储空间
需要先进行全量备份
---------------------------------------------------------------------------------------------------------
示例：tiup br backup incremental --pd "127.0.0.1:2379" --storage "local:///backup" --lastbackupts 123456
定期执行增量备份
保留多个备份版本
验证备份完整性
d.备份策略
制定备份计划
全量备份 + 增量备份
定期备份，如每天全量，每小时增量
保留多个备份版本
---------------------------------------------------------------------------------------------------------
备份到多个位置
定期测试恢复
监控备份状态
自动化备份流程
02.数据恢复
a.全量恢复
使用 BR 恢复数据
指定备份目录
恢复到新集群或现有集群
验证恢复结果
---------------------------------------------------------------------------------------------------------
示例：tiup br restore full --pd "127.0.0.1:2379" --storage "local:///backup"
恢复前停止业务
恢复时间取决于数据量
恢复后验证数据完整性
b.增量恢复
先恢复全量备份
再恢复增量备份
按时间顺序恢复
验证数据一致性
---------------------------------------------------------------------------------------------------------
示例：先恢复全量，再恢复增量
可以恢复到指定时间点
PITR（Point-in-Time Recovery）
验证恢复结果
c.表级恢复
恢复指定的数据库或表
使用 --db 或 --table 参数
减少恢复时间
适合误删除场景
---------------------------------------------------------------------------------------------------------
示例：tiup br restore table --pd "127.0.0.1:2379" --storage "local:///backup" --db mydb --table mytable
恢复前检查表是否存在
避免覆盖现有数据
验证恢复结果
d.恢复验证
检查数据完整性
验证数据一致性
执行业务测试
对比备份前后数据
---------------------------------------------------------------------------------------------------------
查询关键数据
执行数据校验
检查索引和约束
监控一段时间
03.快照备份
a.快照概述
基于存储快照的备份
备份速度快
对业务影响小
需要存储系统支持
---------------------------------------------------------------------------------------------------------
适合云环境
支持 EBS、云盘等
快照备份是增量的
恢复速度快
b.快照创建
使用云平台或存储系统创建快照
为 TiKV 数据目录创建快照
记录快照时间和版本
定期创建快照
---------------------------------------------------------------------------------------------------------
快照创建几乎瞬间完成
不影响业务性能
可以创建多个快照
管理快照生命周期
c.快照恢复
使用快照恢复数据
创建新卷或恢复现有卷
挂载到 TiKV 节点
启动集群
---------------------------------------------------------------------------------------------------------
恢复速度快
可以恢复到任意快照时间点
验证恢复结果
测试业务功能
d.快照管理
定期创建快照
保留多个快照版本
清理过期快照
监控快照使用情况
---------------------------------------------------------------------------------------------------------
自动化快照管理
设置快照保留策略
监控快照成本
定期测试快照恢复
4.4 [2]数据迁移
01.DM工具
a.DM概述
DM（Data Migration）是 TiDB 的数据迁移工具
支持从 MySQL 迁移到 TiDB
支持全量迁移和增量迁移
支持数据过滤和转换
---------------------------------------------------------------------------------------------------------
安装 DM：tiup install dm
查看版本：tiup dm --version
支持多源合并迁移
支持分库分表合并
b.全量迁移
迁移 MySQL 的全量数据
使用 Dumpling 导出数据
使用 TiDB Lightning 导入数据
验证迁移结果
---------------------------------------------------------------------------------------------------------
导出：tiup dumpling -h mysql-host -P 3306 -u root -p password -o /data/dump
导入：tiup tidb-lightning -config lightning.toml
迁移时间取决于数据量
迁移过程可以并行
c.增量迁移
迁移 MySQL 的增量数据
基于 binlog 实现
实时同步数据变更
支持断点续传
---------------------------------------------------------------------------------------------------------
配置 DM 任务
启动增量同步
监控同步延迟
处理同步错误
d.迁移策略
全量迁移 + 增量迁移
先全量迁移历史数据
再增量同步实时数据
切换时停止写入，确保数据一致
---------------------------------------------------------------------------------------------------------
制定迁移计划
在测试环境验证
准备回滚方案
监控迁移过程
02.TiDB Lightning
a.Lightning概述
TiDB Lightning 是快速导入工具
支持大量数据快速导入
支持物理导入和逻辑导入
适合初始化数据
---------------------------------------------------------------------------------------------------------
物理导入：直接生成 SST 文件
逻辑导入：通过 SQL 导入
物理导入速度更快
逻辑导入更灵活
b.物理导入
生成 SST 文件
直接导入到 TiKV
导入速度极快
适合大量数据导入
---------------------------------------------------------------------------------------------------------
配置 Lightning
准备数据文件（SQL 或 CSV）
执行导入：tiup tidb-lightning -config lightning.toml
监控导入进度
c.逻辑导入
通过 SQL 语句导入
使用 TiDB 的 SQL 接口
导入过程对业务影响小
适合在线导入
---------------------------------------------------------------------------------------------------------
配置 Lightning 使用逻辑导入模式
执行导入
监控导入进度
验证导入结果
d.导入优化
调整并行度
优化数据文件格式
使用合适的导入模式
监控资源使用
---------------------------------------------------------------------------------------------------------
物理导入需要停止写入
逻辑导入可以在线进行
根据业务需求选择
测试导入性能
03.TiCDC工具
a.TiCDC概述
TiCDC 是变更数据捕获工具
实时捕获 TiDB 的数据变更
支持同步到 MySQL、Kafka 等
支持数据订阅
---------------------------------------------------------------------------------------------------------
安装 TiCDC：tiup install cdc
查看版本：tiup cdc version
支持多种下游系统
支持数据过滤和转换
b.创建同步任务
配置 TiCDC 任务
指定源和目标
配置同步规则
启动同步任务
---------------------------------------------------------------------------------------------------------
示例：tiup cdc cli changefeed create --pd="http://127.0.0.1:2379" --sink-uri="mysql://user:password@host:port/"
支持同步到 MySQL
支持同步到 Kafka
支持自定义下游
c.监控同步
监控同步延迟
监控同步状态
处理同步错误
优化同步性能
---------------------------------------------------------------------------------------------------------
查看同步状态：tiup cdc cli changefeed list
查看同步详情：tiup cdc cli changefeed query
监控延迟指标
及时处理异常
d.使用场景
数据同步：TiDB 到 MySQL
数据订阅：订阅数据变更
数据分发：分发到多个下游
实时数据仓库：同步到数据仓库
---------------------------------------------------------------------------------------------------------
灾备：同步到备份集群
读写分离：同步到只读副本
数据集成：集成到其他系统
实时分析：同步到分析系统
4.5 [2]监控告警
01.Prometheus监控
a.监控架构
Prometheus 收集监控指标
Grafana 展示监控面板
AlertManager 处理告警
各组件暴露 metrics 接口
---------------------------------------------------------------------------------------------------------
TiDB Server：http://ip:10080/metrics
TiKV：http://ip:20180/metrics
PD：http://ip:2379/metrics
Prometheus 定期拉取指标
b.监控指标
QPS：每秒查询数
延迟：P99、P95、平均延迟
错误率：失败请求比例
连接数：活跃连接数
---------------------------------------------------------------------------------------------------------
资源使用：CPU、内存、磁盘、网络
TiKV：Region 数量、Leader 数量、IO 吞吐量
PD：TSO 分配速度、调度任务
慢查询：执行时间超过阈值的查询
c.Grafana面板
TiDB Dashboard：TiDB Server 监控
TiKV Dashboard：TiKV 监控
PD Dashboard：PD 监控
Overview Dashboard：集群概览
---------------------------------------------------------------------------------------------------------
访问 Grafana：http://monitoring-host:3000
默认用户名密码：admin/admin
自定义监控面板
导出导入面板配置
d.自定义监控
添加自定义指标
创建自定义面板
配置数据源
设置刷新间隔
---------------------------------------------------------------------------------------------------------
使用 PromQL 查询指标
创建变量和模板
设置阈值和告警
分享面板配置
02.告警配置
a.告警规则
配置告警规则文件
定义告警条件
设置告警级别
配置告警持续时间
---------------------------------------------------------------------------------------------------------
示例：TiDB Server 不可用
示例：TiKV 磁盘使用率超过 80%
示例：慢查询数量超过阈值
示例：Region 数量不均衡
b.告警通知
配置 AlertManager
设置通知渠道
支持邮件、钉钉、企业微信、Slack 等
配置通知模板
---------------------------------------------------------------------------------------------------------
配置通知分组
避免告警风暴
设置告警抑制规则
配置告警路由
c.告警处理
及时响应告警
分析告警原因
采取相应措施
记录处理过程
---------------------------------------------------------------------------------------------------------
建立告警响应流程
定义告警级别和处理时间
P0：立即处理
P1：1小时内处理
---------------------------------------------------------------------------------------------------------
P2：4小时内处理
P3：24小时内处理
定期回顾告警
优化告警规则
d.告警优化
减少误报
调整告警阈值
优化告警规则
定期评估告警效果
---------------------------------------------------------------------------------------------------------
避免告警疲劳
合并相关告警
设置告警静默期
持续改进告警系统
03.性能监控
a.慢查询监控
监控慢查询日志
分析慢查询原因
优化慢查询
设置慢查询阈值
---------------------------------------------------------------------------------------------------------
查看慢查询：SELECT * FROM information_schema.slow_query;
分析执行计划
优化索引和 SQL
监控慢查询趋势
b.资源监控
监控 CPU 使用率
监控内存使用率
监控磁盘使用率和 IO
监控网络流量
---------------------------------------------------------------------------------------------------------
设置资源告警阈值
及时扩容
优化资源使用
避免资源瓶颈
c.事务监控
监控事务冲突率
监控事务执行时间
监控事务大小
监控事务失败率
---------------------------------------------------------------------------------------------------------
分析事务冲突原因
优化事务逻辑
调整事务模式
监控事务趋势
d.集群健康监控
监控节点状态
监控 Region 分布
监控 Leader 分布
监控数据均衡
---------------------------------------------------------------------------------------------------------
检查节点是否在线
检查 Region 是否健康
检查 Leader 是否均衡
及时处理异常
4.6 [2]安全加固
01.认证安全
a.用户认证
使用强密码策略
定期更换密码
禁用默认账户
使用最小权限原则
---------------------------------------------------------------------------------------------------------
创建专用账户
避免使用 root 账户
定期审查用户权限
删除不用的账户
b.SSL/TLS加密
启用 SSL/TLS 连接
配置证书
强制使用加密连接
定期更新证书
---------------------------------------------------------------------------------------------------------
生成证书：使用 openssl 或 cfssl
配置 TiDB Server 使用 SSL
配置客户端使用 SSL
验证加密连接
c.身份验证插件
支持多种认证插件
mysql_native_password
caching_sha2_password
配置认证插件
---------------------------------------------------------------------------------------------------------
创建用户时指定插件
示例：CREATE USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
根据需求选择插件
注意兼容性
d.连接限制
限制连接来源
使用主机名或 IP 限制
配置防火墙规则
使用白名单
---------------------------------------------------------------------------------------------------------
示例：CREATE USER 'user'@'192.168.1.%' IDENTIFIED BY 'password';
只允许特定 IP 连接
使用 VPN 或专线
定期审查连接规则
02.权限管理
a.权限分级
全局权限：*.*
数据库权限：dbname.*
表权限：dbname.tablename
列权限：特定列
---------------------------------------------------------------------------------------------------------
遵循最小权限原则
只授予必要的权限
定期审查权限
及时回收权限
b.角色管理
创建角色
授予角色权限
将角色授予用户
使用角色简化权限管理
---------------------------------------------------------------------------------------------------------
示例：CREATE ROLE 'app_read';
示例：GRANT SELECT ON mydb.* TO 'app_read';
示例：GRANT 'app_read' TO 'user'@'%';
角色可以嵌套
c.权限审计
定期审查用户权限
记录权限变更
监控权限使用情况
发现异常及时处理
---------------------------------------------------------------------------------------------------------
查看用户权限：SHOW GRANTS FOR 'user'@'%';
记录权限变更日志
使用审计工具
定期生成权限报告
d.敏感数据保护
加密敏感数据
使用脱敏技术
限制敏感数据访问
记录敏感数据访问日志
---------------------------------------------------------------------------------------------------------
使用应用层加密
使用数据库加密函数
配置列级权限
监控敏感数据访问
03.网络安全
a.防火墙配置
配置防火墙规则
只开放必要的端口
限制访问来源
使用安全组
---------------------------------------------------------------------------------------------------------
TiDB Server：4000（MySQL 协议）
TiDB Server：10080（状态端口）
TiKV：20160（客户端端口）
PD：2379（客户端端口）
---------------------------------------------------------------------------------------------------------
关闭不必要的端口
使用 iptables 或云安全组
定期审查防火墙规则
测试防火墙配置
b.网络隔离
使用 VPC 或 VLAN 隔离
分离管理网络和业务网络
使用堡垒机访问
限制跨网络访问
---------------------------------------------------------------------------------------------------------
生产环境与测试环境隔离
数据库网络与应用网络隔离
使用专线或 VPN
监控网络流量
c.DDoS防护
使用 DDoS 防护服务
限制连接速率
配置连接超时
监控异常流量
---------------------------------------------------------------------------------------------------------
使用云服务商的 DDoS 防护
配置负载均衡器
限制单 IP 连接数
及时响应攻击
d.入侵检测
部署入侵检测系统
监控异常访问
记录访问日志
及时发现和处理入侵
---------------------------------------------------------------------------------------------------------
使用 IDS/IPS 系统
监控登录失败次数
监控异常 SQL 语句
定期分析日志
04.数据安全
a.数据加密
启用传输加密（SSL/TLS）
启用存储加密
加密备份数据
管理加密密钥
---------------------------------------------------------------------------------------------------------
TiKV 支持静态数据加密
配置加密算法
定期轮换密钥
安全存储密钥
b.数据备份
定期备份数据
备份到多个位置
加密备份数据
测试备份恢复
---------------------------------------------------------------------------------------------------------
制定备份策略
自动化备份流程
监控备份状态
定期演练恢复
c.数据脱敏
对敏感数据脱敏
生产数据脱敏后用于测试
使用脱敏函数
配置脱敏规则
---------------------------------------------------------------------------------------------------------
手机号脱敏：138****1234
身份证脱敏：110***********1234
邮箱脱敏：abc***@example.com
使用专业脱敏工具
d.数据审计
记录数据访问日志
监控数据变更
定期审计数据操作
发现异常及时处理
---------------------------------------------------------------------------------------------------------
启用审计日志
记录 DDL 和 DML 操作
记录登录和权限变更
使用审计工具分析
5 TiDB实战
5.1 [1]安装部署
01.环境准备
a.硬件要求
TiDB Server：8核 CPU、16GB 内存、SSD 存储
TiKV：16核 CPU、32GB 内存、NVMe SSD 存储
PD：4核 CPU、8GB 内存、SSD 存储
TiFlash：16核 CPU、32GB 内存、NVMe SSD 存储
---------------------------------------------------------------------------------------------------------
生产环境建议配置更高
TiKV 对 IO 性能要求高，建议使用 NVMe SSD
网络带宽建议 10Gbps
建议使用专用服务器
b.操作系统
支持 Linux 操作系统
推荐 CentOS 7.3+ 或 Ubuntu 18.04+
内核版本 3.10+
禁用 swap
---------------------------------------------------------------------------------------------------------
配置时间同步（NTP）
配置防火墙规则
禁用 SELinux
优化系统参数
c.网络规划
规划网络拓扑
配置网络带宽
配置防火墙规则
测试网络连通性
---------------------------------------------------------------------------------------------------------
建议使用万兆网络
配置网络隔离
使用专用网络
测试网络延迟
d.存储规划
规划存储容量
选择存储类型
配置 RAID
规划数据目录
---------------------------------------------------------------------------------------------------------
TiKV 数据目录使用独立磁盘
日志目录使用独立磁盘
预留足够的存储空间
监控磁盘使用情况
02.TiUP部署
a.安装TiUP
下载安装脚本
执行安装命令
配置环境变量
验证安装
---------------------------------------------------------------------------------------------------------
安装命令：curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
配置环境变量：source ~/.bashrc
验证：tiup --version
更新 TiUP：tiup update --self
b.编写拓扑文件
创建拓扑配置文件
配置各组件节点
配置组件参数
配置目录路径
---------------------------------------------------------------------------------------------------------
示例拓扑文件：topology.yaml
配置 TiDB Server 节点
配置 TiKV 节点
配置 PD 节点
---------------------------------------------------------------------------------------------------------
配置监控节点
配置 TiFlash 节点（可选）
配置全局参数
配置组件参数
c.执行部署
检查环境
执行部署命令
等待部署完成
验证部署结果
---------------------------------------------------------------------------------------------------------
检查环境：tiup cluster check topology.yaml --user root
修复问题：tiup cluster check topology.yaml --apply --user root
部署集群：tiup cluster deploy my-cluster v7.5.0 topology.yaml --user root
启动集群：tiup cluster start my-cluster
d.验证部署
检查集群状态
连接 TiDB
执行测试查询
查看监控面板
---------------------------------------------------------------------------------------------------------
查看状态：tiup cluster display my-cluster
连接 TiDB：mysql -h 127.0.0.1 -P 4000 -u root
执行查询：SELECT tidb_version();
访问 Grafana：http://monitoring-host:3000
03.Docker部署
a.Docker Compose
使用 Docker Compose 部署
适合开发和测试环境
快速启动集群
方便管理
---------------------------------------------------------------------------------------------------------
下载 docker-compose.yml
启动集群：docker-compose up -d
查看状态：docker-compose ps
停止集群：docker-compose down
b.Kubernetes部署
使用 TiDB Operator 部署
适合生产环境
支持自动化运维
支持弹性伸缩
---------------------------------------------------------------------------------------------------------
安装 TiDB Operator
创建 TiDB 集群 CR
应用配置：kubectl apply -f tidb-cluster.yaml
查看状态：kubectl get tidbcluster
c.容器配置
配置资源限制
配置存储卷
配置网络
配置环境变量
---------------------------------------------------------------------------------------------------------
CPU 和内存限制
持久化存储配置
网络模式配置
日志配置
d.容器监控
配置 Prometheus
配置 Grafana
查看监控指标
配置告警
---------------------------------------------------------------------------------------------------------
使用 Kubernetes 监控
集成云监控服务
配置日志收集
配置链路追踪
5.2 [1]配置管理
01.TiDB配置
a.连接配置
host：监听地址，默认 0.0.0.0
port：监听端口，默认 4000
socket：Unix socket 文件路径
max-connections：最大连接数，默认 0（无限制）
---------------------------------------------------------------------------------------------------------
token-limit：并发 token 数量
mem-quota-query：单个查询内存限制
oom-action：内存不足时的操作
tmp-storage-path：临时文件存储路径
b.日志配置
log.level：日志级别，默认 info
log.format：日志格式，默认 text
log.file.filename：日志文件路径
log.file.max-size：单个日志文件最大大小
---------------------------------------------------------------------------------------------------------
log.file.max-days：日志保留天数
log.file.max-backups：日志文件最大数量
slow-threshold：慢查询阈值
expensive-threshold：expensive 查询阈值
c.性能配置
performance.max-procs：最大 CPU 核数
performance.max-memory：最大内存使用
performance.stmt-count-limit：语句数量限制
performance.txn-total-size-limit：事务大小限制
---------------------------------------------------------------------------------------------------------
prepared-plan-cache.enabled：是否启用 prepared plan cache
prepared-plan-cache.capacity：plan cache 容量
tikv-client.grpc-connection-count：与 TiKV 的连接数
tikv-client.grpc-keepalive-time：keepalive 时间
d.事务配置
txn-local-latches.enabled：是否启用本地锁
txn-local-latches.capacity：本地锁容量
compatible-kill-query：兼容 MySQL kill 语句
check-mb4-value-in-utf8：检查 utf8mb4 值
---------------------------------------------------------------------------------------------------------
treat-old-version-utf8-as-utf8mb4：兼容旧版本 utf8
alter-primary-key：是否允许修改主键
server-version：服务器版本号
repair-mode：修复模式
02.TiKV配置
a.存储配置
storage.data-dir：数据目录
storage.block-cache.capacity：block cache 大小
storage.scheduler-concurrency：调度器并发数
storage.scheduler-worker-pool-size：调度器工作线程数
---------------------------------------------------------------------------------------------------------
rocksdb.max-open-files：最大打开文件数
rocksdb.max-background-jobs：后台任务数
rocksdb.wal-dir：WAL 目录
rocksdb.wal-ttl-seconds：WAL 保留时间
b.Raft配置
raftstore.sync-log：是否同步写 Raft 日志
raftstore.raft-base-tick-interval：Raft 基础 tick 间隔
raftstore.raft-heartbeat-ticks：心跳 tick 数
raftstore.raft-election-timeout-ticks：选举超时 tick 数
---------------------------------------------------------------------------------------------------------
raftstore.raft-min-election-timeout-ticks：最小选举超时
raftstore.raft-max-election-timeout-ticks：最大选举超时
raftstore.raft-max-size-per-msg：单个消息最大大小
raftstore.raft-max-inflight-msgs：最大 inflight 消息数
c.Coprocessor配置
coprocessor.split-region-on-table：是否按表分裂 Region
coprocessor.batch-split-limit：批量分裂限制
coprocessor.region-max-size：Region 最大大小
coprocessor.region-split-size：Region 分裂大小
---------------------------------------------------------------------------------------------------------
coprocessor.region-max-keys：Region 最大键数
coprocessor.region-split-keys：Region 分裂键数
coprocessor.consistency-check-interval：一致性检查间隔
readpool.coprocessor.use-unified-pool：是否使用统一线程池
d.GC配置
gc.ratio-threshold：GC 比例阈值
gc.batch-keys：GC 批量键数
gc.max-write-bytes-per-sec：GC 最大写入速度
gc.enable-compaction-filter：是否启用 compaction filter
---------------------------------------------------------------------------------------------------------
gc.compaction-filter-skip-version-check：跳过版本检查
gc-worker.gc-worker-pool-size：GC 工作线程数
gc-worker.gc-worker-concurrency：GC 并发数
gc-worker.gc-worker-max-batch-size：GC 最大批量大小
03.PD配置
a.调度配置
schedule.max-snapshot-count：最大快照数
schedule.max-pending-peer-count：最大 pending peer 数
schedule.max-merge-region-size：最大合并 Region 大小
schedule.max-merge-region-keys：最大合并 Region 键数
---------------------------------------------------------------------------------------------------------
schedule.split-merge-interval：分裂合并间隔
schedule.patrol-region-interval：巡检 Region 间隔
schedule.max-store-down-time：节点下线最大时间
schedule.leader-schedule-limit：Leader 调度限制
---------------------------------------------------------------------------------------------------------
schedule.region-schedule-limit：Region 调度限制
schedule.replica-schedule-limit：副本调度限制
schedule.merge-schedule-limit：合并调度限制
schedule.hot-region-schedule-limit：热点 Region 调度限制
b.副本配置
replication.max-replicas：最大副本数，默认 3
replication.location-labels：位置标签
replication.strictly-match-label：是否严格匹配标签
replication.enable-placement-rules：是否启用放置规则
---------------------------------------------------------------------------------------------------------
label-property：标签属性
isolation-level：隔离级别
配置跨机架、跨数据中心部署
配置副本分布策略
c.集群配置
cluster-version：集群版本
enable-prevote：是否启用 prevote
enable-grpc-gateway：是否启用 gRPC gateway
dashboard.tidb-cacert-path：TiDB CA 证书路径
---------------------------------------------------------------------------------------------------------
dashboard.tidb-cert-path：TiDB 证书路径
dashboard.tidb-key-path：TiDB 密钥路径
dashboard.public-path-prefix：公共路径前缀
dashboard.enable-telemetry：是否启用遥测
d.日志配置
log.level：日志级别
log.format：日志格式
log.file.filename：日志文件路径
log.file.max-size：日志文件最大大小
---------------------------------------------------------------------------------------------------------
log.file.max-days：日志保留天数
log.file.max-backups：日志文件最大数量
metric.interval：指标收集间隔
metric.address：指标推送地址
5.3 [2]高可用架构
01.多副本部署
a.副本配置
配置副本数量，默认 3
副本分布在不同节点
通过 Raft 协议保证一致性
自动故障转移
---------------------------------------------------------------------------------------------------------
配置副本数：ALTER PLACEMENT POLICY SET REPLICAS=3;
配置副本分布：使用 location-labels
监控副本状态
确保副本健康
b.跨机架部署
副本分布在不同机架
避免单机架故障
配置 location-labels
配置放置规则
---------------------------------------------------------------------------------------------------------
示例：location-labels = ["zone", "rack", "host"]
配置 TiKV 标签
配置 PD 调度策略
验证副本分布
c.跨数据中心部署
副本分布在不同数据中心
实现异地容灾
考虑网络延迟
配置放置规则
---------------------------------------------------------------------------------------------------------
三数据中心部署：2+2+1 或 2+1+1
五数据中心部署：2+2+2+1+1
配置就近读取
监控跨数据中心延迟
d.故障转移
自动检测节点故障
自动选举新 Leader
自动迁移 Region
RPO = 0，RTO < 30秒
---------------------------------------------------------------------------------------------------------
监控故障转移过程
验证数据一致性
测试故障场景
制定故障预案
02.负载均衡
a.TiDB负载均衡
使用负载均衡器分发请求
支持多种负载均衡策略
健康检查
自动剔除故障节点
---------------------------------------------------------------------------------------------------------
使用 HAProxy、Nginx、F5 等
配置轮询、最少连接等策略
配置健康检查端口：10080
监控负载均衡状态
b.TiKV负载均衡
PD 自动调度 Region
Leader 均衡分布
数据均衡分布
热点调度
---------------------------------------------------------------------------------------------------------
监控 Region 分布
监控 Leader 分布
调整调度策略
处理热点问题
c.读写分离
使用 Follower Read
分担 Leader 读压力
提升读性能
配置读取策略
---------------------------------------------------------------------------------------------------------
配置 tidb_replica_read
监控读取延迟
根据业务需求选择策略
测试读写分离效果
d.连接池
使用连接池管理连接
减少连接开销
提升性能
配置连接池参数
---------------------------------------------------------------------------------------------------------
配置最小连接数
配置最大连接数
配置连接超时
监控连接池使用情况
03.灾备方案
a.同城双活
两个数据中心部署
数据实时同步
双向读写
自动故障切换
---------------------------------------------------------------------------------------------------------
配置跨数据中心副本
配置就近访问
监控同步延迟
定期演练切换
b.异地灾备
主备数据中心
数据异步同步
主中心故障时切换到备中心
RTO 和 RPO 根据需求配置
---------------------------------------------------------------------------------------------------------
使用 TiCDC 同步数据
配置同步延迟监控
制定切换流程
定期演练切换
c.备份恢复
定期全量备份
实时增量备份
备份到多个位置
定期测试恢复
---------------------------------------------------------------------------------------------------------
使用 BR 工具备份
备份到云存储
加密备份数据
自动化备份流程
d.演练方案
定期进行灾备演练
测试故障切换
测试数据恢复
优化灾备方案
---------------------------------------------------------------------------------------------------------
制定演练计划
记录演练过程
分析演练结果
持续改进方案
5.4 [2]性能调优实践
01.SQL调优
a.慢查询分析
查看慢查询日志
分析慢查询原因
优化 SQL 语句
添加或优化索引
---------------------------------------------------------------------------------------------------------
查询慢查询：SELECT * FROM information_schema.slow_query WHERE time > '2024-01-01';
使用 EXPLAIN 分析执行计划
检查是否使用索引
优化 JOIN 和子查询
b.索引优化
为常用查询添加索引
删除冗余索引
使用覆盖索引
定期分析索引使用情况
---------------------------------------------------------------------------------------------------------
使用 EXPLAIN 检查索引使用
避免索引失效
优化复合索引顺序
监控索引大小
c.查询重写
简化复杂查询
拆分大查询
使用 JOIN 代替子查询
避免使用 SELECT *
---------------------------------------------------------------------------------------------------------
使用 UNION ALL 代替 UNION
避免在 WHERE 中使用函数
使用 LIMIT 限制结果集
批量操作代替逐条操作
d.统计信息
定期收集统计信息
使用 ANALYZE TABLE
配置自动收集
监控统计信息准确性
---------------------------------------------------------------------------------------------------------
手动收集：ANALYZE TABLE users;
配置自动收集策略
关注统计信息过期
更新统计信息后验证查询计划
02.系统调优
a.参数调优
调整 TiDB 参数
调整 TiKV 参数
调整 PD 参数
根据业务特点调整
---------------------------------------------------------------------------------------------------------
内存参数：tidb_mem_quota_query
并发参数：tidb_executor_concurrency
缓存参数：tikv_client_cache_size
监控参数调整效果
b.资源调优
优化 CPU 使用
优化内存使用
优化磁盘 IO
优化网络带宽
---------------------------------------------------------------------------------------------------------
监控资源使用情况
识别资源瓶颈
扩展资源或优化使用
使用资源隔离
c.集群调优
优化 Region 大小
优化副本数量
优化调度策略
优化热点处理
---------------------------------------------------------------------------------------------------------
调整 Region 大小：96MB
配置副本数：3 或 5
调整调度参数
处理热点 Region
d.监控调优
监控关键指标
分析性能瓶颈
制定优化方案
验证优化效果
---------------------------------------------------------------------------------------------------------
监控 QPS、延迟、错误率
监控资源使用
分析慢查询
持续优化
5.5 [2]故障排查
01.常见问题
a.连接问题
无法连接 TiDB
连接超时
连接数过多
连接频繁断开
---------------------------------------------------------------------------------------------------------
检查网络连通性
检查防火墙规则
检查 TiDB Server 状态
检查连接数限制
b.性能问题
查询慢
写入慢
CPU 使用率高
内存使用率高
---------------------------------------------------------------------------------------------------------
分析慢查询
检查索引使用
检查资源使用
优化 SQL 和配置
c.数据问题
数据不一致
数据丢失
数据重复
数据损坏
---------------------------------------------------------------------------------------------------------
检查副本状态
检查 Region 健康
检查事务日志
使用备份恢复
d.集群问题
节点下线
Region 不均衡
Leader 不均衡
热点问题
---------------------------------------------------------------------------------------------------------
检查节点状态
检查 PD 调度
调整调度策略
处理热点 Region
02.诊断工具
a.EXPLAIN分析
使用 EXPLAIN 查看执行计划
分析扫描行数
检查索引使用
优化查询
---------------------------------------------------------------------------------------------------------
EXPLAIN SELECT * FROM users WHERE id = 1;
EXPLAIN ANALYZE：查看实际执行情况
关注 type、rows、Extra 字段
优化执行计划
b.慢查询日志
查看慢查询日志
分析慢查询原因
优化慢查询
监控慢查询趋势
---------------------------------------------------------------------------------------------------------
查询慢查询：SELECT * FROM information_schema.slow_query;
分析执行时间、扫描行数
优化 SQL 和索引
设置慢查询阈值
c.监控面板
查看 Grafana 监控
分析关键指标
识别异常
定位问题
---------------------------------------------------------------------------------------------------------
查看 QPS、延迟、错误率
查看资源使用情况
查看组件状态
分析趋势和异常
d.日志分析
查看组件日志
搜索错误和警告
分析日志内容
定位问题原因
---------------------------------------------------------------------------------------------------------
TiDB 日志：{deploy_dir}/log/tidb.log
TiKV 日志：{deploy_dir}/log/tikv.log
PD 日志：{deploy_dir}/log/pd.log
使用 grep 搜索关键字
03.故障处理
a.节点故障
检测节点故障
自动故障转移
修复或替换节点
验证恢复
---------------------------------------------------------------------------------------------------------
检查节点状态
等待自动故障转移
修复故障节点
重新加入集群
b.数据恢复
使用备份恢复数据
选择合适的备份版本
执行恢复操作
验证数据完整性
---------------------------------------------------------------------------------------------------------
使用 BR 恢复数据
恢复到指定时间点
验证数据一致性
测试业务功能
c.性能恢复
识别性能瓶颈
优化 SQL 和索引
调整配置参数
扩展集群资源
---------------------------------------------------------------------------------------------------------
分析慢查询
优化执行计划
调整系统参数
扩容节点
d.应急预案
制定应急预案
定义故障级别
明确处理流程
定期演练
---------------------------------------------------------------------------------------------------------
P0：立即处理
P1：1小时内处理
P2：4小时内处理
P3：24小时内处理
5.6 [2]最佳实践
01.设计最佳实践
a.表设计
合理设计表结构
选择合适的数据类型
定义主键和索引
避免过度范式化
---------------------------------------------------------------------------------------------------------
使用自增主键或 UUID
避免使用过长的字段
合理使用 JSON 类型
考虑查询模式设计表
b.索引设计
为常用查询创建索引
使用复合索引
使用覆盖索引
避免冗余索引
---------------------------------------------------------------------------------------------------------
遵循最左前缀原则
选择性高的列放在前面
定期分析索引使用情况
删除未使用的索引
c.分区设计
使用分区表管理大表
选择合适的分区类型
合理设计分区键
定期维护分区
---------------------------------------------------------------------------------------------------------
按时间分区适合时序数据
按哈希分区避免热点
定期添加删除分区
监控分区大小
d.事务设计
控制事务大小
避免长事务
选择合适的事务模式
处理事务冲突
---------------------------------------------------------------------------------------------------------
单个事务不超过 100MB
及时提交或回滚
根据业务选择乐观或悲观事务
实现重试机制
02.开发最佳实践
a.SQL编写
使用参数化查询
避免 SQL 注入
使用批量操作
优化查询性能
---------------------------------------------------------------------------------------------------------
使用 prepared statement
避免拼接 SQL
批量插入代替逐条插入
使用 LIMIT 限制结果集
b.连接管理
使用连接池
合理配置连接数
及时释放连接
处理连接异常
---------------------------------------------------------------------------------------------------------
配置连接池参数
避免连接泄漏
设置连接超时
实现连接重试
c.错误处理
正确处理异常
实现重试机制
记录错误日志
监控错误率
---------------------------------------------------------------------------------------------------------
捕获并处理数据库异常
实现指数退避重试
记录详细错误信息
设置错误告警
d.性能优化
优化 SQL 语句
使用缓存
异步处理
批量操作
---------------------------------------------------------------------------------------------------------
避免 N+1 查询
使用 Redis 等缓存
使用消息队列异步处理
批量读写代替逐条操作
03.运维最佳实践
a.监控告警
配置完善的监控
设置合理的告警
及时响应告警
定期分析监控数据
---------------------------------------------------------------------------------------------------------
监控关键指标
配置告警规则
建立告警响应流程
持续优化监控
b.备份恢复
制定备份策略
定期备份数据
测试备份恢复
自动化备份流程
---------------------------------------------------------------------------------------------------------
全量备份 + 增量备份
备份到多个位置
定期演练恢复
监控备份状态
c.容量规划
预估数据增长
规划存储容量
规划计算资源
提前扩容
---------------------------------------------------------------------------------------------------------
监控资源使用趋势
预留足够的容量
制定扩容计划
避免资源瓶颈
d.版本升级
定期升级版本
在测试环境验证
制定升级计划
准备回滚方案
---------------------------------------------------------------------------------------------------------
阅读版本发布说明
了解不兼容变更
使用滚动升级
监控升级过程
04.安全最佳实践
a.访问控制
使用最小权限原则
定期审查权限
使用强密码
启用 SSL/TLS
---------------------------------------------------------------------------------------------------------
创建专用账户
定期更换密码
限制连接来源
加密传输数据
b.数据保护
加密敏感数据
脱敏测试数据
定期备份
监控数据访问
---------------------------------------------------------------------------------------------------------
使用加密函数
脱敏生产数据
备份到安全位置
记录访问日志
c.网络安全
配置防火墙
使用网络隔离
限制端口访问
监控网络流量
---------------------------------------------------------------------------------------------------------
只开放必要端口
使用 VPC 或 VLAN
配置安全组
检测异常流量
d.审计合规
启用审计日志
记录关键操作
定期审计
满足合规要求
---------------------------------------------------------------------------------------------------------
记录登录和权限变更
记录 DDL 和 DML 操作
定期生成审计报告
符合行业标准