分库分表的痛

单台 MySQL 容量到了瓶颈，通常第一反应是分库分表（本站另有《分库分表与分布式数据库实战》）。但手工分片带来一堆麻烦：跨分片 JOIN、分布式事务、扩容时数据迁移、应用层写大量分片路由代码。TiDB 这类 NewSQL 数据库的出现，就是想在保留 MySQL 习惯的同时，把“自动水平扩展”这件事交给数据库自己做。

它对外就是一个兼容 MySQL 协议的库：应用几乎不用改 SQL、客户端照旧连，但底层数据自动分散到多台机器上，加机器就能扩容。

本文核心知识点
  • TiDB 层计算与 SQL 解析，无状态可横向扩。
  • TiKV行存分布式 KV 引擎，负责落盘与复制。
  • PD调度中心，管元数据与负载均衡。
  • HTAP同一份数据同时支撑事务与分析。
TiDB 分布式数据库配图：蓝色渐变背景上方一组接入网关方块，下方一圈大小不一的存储节点圆柱，节点之间由网状连线与中央发光共识环连接，扁平科技插画
上方是无状态的计算节点，下方是分布式存储节点，中央环是统一调度。

TiDB 三层架构

TiDB 由三大组件组成，各司其职：

  • TiDB Server：计算层，负责解析 SQL、生成执行计划，本身不存数据、无状态，加机器就提升查询能力。
  • TiKV：存储层，把数据按区间切成 Region、多副本用 Raft 协议复制保证一致，真正落盘的地方。
  • PD（Placement Driver）：调度大脑，存元数据、给 Region 做负载均衡、决定副本放哪台机器。

读写流程：应用连到 TiDB Server，它把请求下发到持有该数据的 TiKV Region，PD 在背后不断帮你把热点 Region 打散、把数据自动再均衡。这一切对应用透明，你只觉得“这是一个巨大的 MySQL”。

MySQL 兼容与透明扩展

因为走 MySQL 协议，原来的 MySQL 客户端、ORM、mysqldump 基本能直接用。数据量大了，不需要像手工分片那样预先定分片键、改应用路由——TiKV 自动把数据按 Region 拆开、自动迁移，扩容就是加入新机器，PD 自动把一部分 Region 挪过去。

-- 用法和 MySQL 几乎一样
CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  user_id BIGINT,
  amount DECIMAL(10,2)
);
-- 应用直接连，不用关心数据落在哪个节点

代价是：因为要分布式协调，单点延迟通常比原生 MySQL 略高，且某些 MySQL 边角语法/存储引擎特性并不完全兼容，迁移前要用官方兼容性清单核对。

分布式事务

跨多个 Region 的写入怎么保证原子性？TiKV 用基于 Raft 的多副本 + Percolator 事务模型（两阶段提交的变种）：先预写、再提交，靠 PD 分配全局时间戳保证线性一致。应用写一条 SQL，就算它修改的数据分布在多个节点，对开发者来说仍是一个完整事务，ACID 语义与单机 MySQL 一致。

这正是它比手工分片省心的地方：跨库 JOIN 和分布式事务由数据库内部完成，不用在应用层自己写补偿逻辑。

HTAP：一份数据两种引擎

传统方案里，OLTP（交易）用 MySQL，OLAP（分析）要再导一套数仓，数据两份、延迟还高。TiDB 的特色是 TiFlash：在同一套数据上额外建一个列式副本。行存 TiKV 负责高频点写点查，列存 TiFlash 负责大表扫描分析，二者通过 Raft 自动同步，应用写一次、分析直接读列存。

于是“交易和报表跑在同一套库上”成为可能，不用再为实时分析单独搭一套 ClickHouse（本站另有《ClickHouse 入门》），但超大规模纯分析场景仍需权衡。

扩缩容与运维

加节点：新机器加入集群后，PD 会自动把 Region 逐步迁移过去，无需停机。减节点则先做 Region 迁出、再下线。日常运维要盯：Region 分布是否均衡、有没有热点 Region、Raft 副本健康、慢 SQL。

因为组件多（TiDB/TiKV/PD/TiFlash），监控和部署比 MySQL 复杂，生产上常用官方提供的部署工具和 Dashboard，别裸奔。