TiDB 深度解读

“MySQL 兼容的原生分布式 HTAP 标杆 – 一套系统同时吃下事务和分析”

一句话定位

TiDB 是 PingCAP 研发的 MySQL 兼容原生分布式 HTAP 数据库，通过存算分离架构和双存储引擎（TiKV 行存 + TiFlash 列存）实现一个集群同时处理 OLTP 和 OLAP 工作负载。

设计哲学上最精彩的地方

TiDB 最精彩的设计决策是用 Raft Learner 打通 TP 和 AP 的数据通道。

想象一家公司里，仓库每天实时记录进出货，财务部需要同样的数据做报表分析。传统做法是每天晚上把仓库数据拷一份给财务（ETL）。TiDB 的做法是：财务部派一个”旁听生”坐在仓库里实时抄笔记（Raft Learner），仓库正常工作完全不受影响，而旁听生的笔记自动整理成报表格式（列存）。这让实时分析成为事务系统的”副产品”，而不是一套独立的基础设施。

从源码看，查询优化器（pkg/planner/cascades/）可以透明地决定一条 SQL 的哪些部分下推到 TiKV（点查快）、哪些部分下推到 TiFlash（扫描聚合快），这个决策对用户完全透明。Cascades 框架包含 Memo 结构、规则引擎和任务调度器，是工业级分布式数据库中少见的完整实现。

生态角色与竞争位置

TiDB（约 41K Star）是 MySQL 兼容阵营的绝对领导者，在国内金融、电商、游戏行业有大量生产部署。它和 CockroachDB 分别代表了 MySQL 和 PostgreSQL 两大生态在分布式领域的标杆。核心竞争壁垒是 HTAP 双引擎能力 – 竞品要么只做 TP（CockroachDB），要么只做 AP，TiDB 两者都做。

多仓库生态是另一个特点：TiDB Server（Go，SQL 层）、TiKV（Rust，KV 存储）、PD（Go，调度）各自独立仓库，语言和关注点清晰分离。

技术亮点速览

自研 SQL Parser：pkg/parser/ 是一个独立可用的 MySQL 兼容解析器，有独立 go.mod，基于 yacc 生成，社区复用度极高。

Plan Cache 机制：pkg/planner/core/plan_cache.go 实现了非 Prepared Statement 的计划缓存，通过 LRU 策略管理，显著降低重复查询优化开销。

向量搜索支持：TiDB 正积极拥抱 AI 场景，已集成向量搜索能力，跟上 YugabyteDB 等竞品的步伐。

局限性与场景边界

TiDB 的 MySQL 兼容性虽高但非 100% – 存储过程、触发器等功能有限。多仓库架构（tidb + tikv + pd + tiflash）带来部署复杂度。HTAP 的 TiFlash 组件需要额外资源，小规模场景可能”杀鸡用牛刀”。 Raft Learner 同步存在秒级延迟，对实时性要求极高的分析场景仍需评估。

本地代码结构

pingcap/tidb (Go)
  pkg/
    parser/           # 独立 MySQL 解析器（有独立 go.mod）
      ast/             # AST 定义（ddl.go, dml.go, expressions.go）
    planner/
      cascades/        # Cascades 优化器框架
      core/            # 计划缓存、逻辑/物理优化
    executor/          # 查询执行引擎
    session/           # 会话管理
    store/             # 存储抽象层（对接 TiKV）
    ddl/               # DDL 执行
    statistics/        # 统计信息收集
  cmd/tidb-server/     # 入口 main

本地关键文件