一、TIDB核心组成部分以及功能
核心组成部分：
- PD：负责调度
- TIDB Server：负责计算
- TIKV:负责存储
功能：
- MySQL 无缝兼容
- 无限水平扩展：计算、存储可独立扩容，数据自动分片，不用手动分库分表
- 强一致高可用：数据多副本备份，节点故障自动恢复，不丢数据、不中断业务
- OLTP+OLAP 一体化：既能跑高并发，又能直接做数据分析
- 简单易运维：自动负载均衡、故障自愈，配套工具支持快速备份恢复、数据同步
二、具体介绍
TIDB Server
作用
解析SQL语句，将实际数据读取，转换为底层的TIKV的执行计划
架构
任务描述：三者负责sql解析和编译（优化），生成执行计划
protocol layer ：处理客户端的连接
parse
compile
具体实现描述：
- 通过协议层读取数据在parse 模块内解析通过词法分析 （lex）【讲sql语句解析成为一个个单位（token），保留关键字】与语法分析（yacc）【生成树形结构（ast）将单位进一步解析】
compile根据树形结构进行优化
具体实现过程
- 通过合法性验证（表是否存在等）进行逻辑优化（sql语句层面优化，多余列去掉等）后进行物理优化（根据统计信息与元数据选择索引 还是全表扫描等）
任务描述：执行执行计划
执行计划交给executor、distsql（扫描表后进行分类）、kv 分批执行执行计划
transaction 与kv负责事务的执行（写操作哇）
PD CLIENT 与tikv client负责关于PD （时间戳的获取）和tikv与TIDB Server之间的交互
任务描述：负责语句执行
shema work startjob
额外模块
membuffer缓存：存储读出来的数据、统计信息与元数据等信息
cache table-热点小表：缓存表不大，访问频繁，不常修改，64MB
访问频繁，tikv形成性能瓶颈：
办法：
- 可以从tikv读入到TIDB Server的cache table中缓存
实现语句：alter table user cache
作用：增加吞吐量
难题：修改，这张表在内存也在tikv中如何修改？先写入cache table会出现数据不一致 ，先写入tikv会使用户读到过期数据。
解决办法（即原理）：
- 有一个缓存租约：tidb_table_cache_lease（/s)，在租约内，用户无法进行写操作（数据来去自如）
- 租约过期：缓存失效，用户的写操作在tikv中（可以读操作）-性能下降
- 操作完毕-租约开启：tikv节点表中更新的数据刷新（refresh）到cache table中，读的用户在cache内读
重点功能
1.关系型数据与kv的转化
聚簇表：用表中原来的主键
key自动变成表名_ 表内的key ------即表名_key+value
- 当数据构成（存入）一个region-96MB(TiDB v8.5 之前)当达到144MB就一分为二，可分布式存储在tikv节点中
随：TiDB v8.5 及之后 region-split-size默认值为256MB
非聚簇表：可有主键，可没有主键
2.垃圾回收
gc机制-------实现mvcc控制
修改时保存不同的数据版本（历史版本），当数据修改错误时，可改
问题：历史数据有点多怎么办，存储空间有压力？
解决：定期清理
实现：在集群中会有一个TIDB Server选为gc leader控制gc，参数safe point要是设置8点，八点以前的数据回收了当然还有个参数gc_life_time默认10min，10min以内，保留历史版本
清理：看是否有锁信息，删除数据，然后清理delete掉的数据等
小声bb：TIDB Server内的gc不是说go语言喔；每个TIDB Server都有一个gc模块
协作关系
1、读写相关模块
按照compile生成的AST解析，执行计划给到executor
executor后面具体走法
- 一些比较复杂的sql查询（eg：表连接，子查询嵌套查询，范围扫描）交给distsql（提供一个简单的select方法（变成单表，但是会涉及多个region）接口给tikv
- 点查（一行零行，例如主键（唯一）索引查询）走KV模块
tikv client负责向tikv发送读写请求
两种请求：
kv模块过来的request
distsql模块过来的request
若是涉及事务还会启动transaction模块（此模块负责二阶段提交以及锁） 事务提交时间：通过pd client拿到一个时间戳
2、在线ddl模块（不阻塞读写）
一个集群有多个TIDB Server
实现操作：同 一时 间在集群中只能有一个TIDB Server在做ddl操作（worker内）
正在ddl的TIDB Server角色是owner，owner内的workers去取job 队列的第一个执行，完成后将次job放入history queue中
JOB流程------多个TIDB Server可同时放入的操作：用户发出一个ddl语句，由start job接收，作为一个任务（job）放在tikv（持久化）任务队列中
schema load 是成为owner角色后 ，将最新的shema 表信息同步到内部shema中，根据这些信息执行job队列
要注意的是owner会变：因为tidb server有任期，会发起选举-激活另外的owner
缓存
具体缓存：
- sql结果（表连接，事务很大）
- 线程存储（活跃的线程）
- 元数据，统计信息（解析，编译，身份认证信息等）
缓存管理参数
tidb_mem_quota_query：控制每条sql的限用缓存大小默认存储量
oom-action：决定当超过限用默认存储量，中断返回error，还是基于日志返回行为，有更近一步的了解
扩展知识：
- 技术栈：指的是完成某项工作或开发某个项目所需的一系列技术、工具和框架 的组合；它通常包括 前端、后端、数据库、操作系统等多个层面的技术集合；核心思想：将多种技术有机地组合在一起，实现特定的功能或目标
- TIDB属于分层架构
更于2025-12-10-0:27:30